4 tips for how to migrate to Drupal

No readers like this yet.
paper planes

Opensource.com

If you have a content-heavy website, then you most definitely have heard of Drupal, an open source content management system (CMS). Maybe you've heard also that Drupal is free, secure, and has a wonderful developer network, which means lots of talent to choose from. So, what are you waiting for?

Well, to jump from your current CMS (or lack thereof) and make the transition to Drupal, you want to know much it costs and exacting what that migration entails. First, there are several factors that have to be taken into an account before any Drupal development company can give you a quote. But, while there isn’t an exact price range for migrating to Drupal, you can do some in-house work to keep your migration costs down and prepare your team for the migration, keeping headaches down too.

Here are 4 tips for how to migrate to Drupal on a budget:

1. Have a migratory plan

Cost is the first thing that hits any organization’s migration agenda. Migrating to any CMS will have its own complexities, but the cost of migration largely depends upon the process that’s being undertaken. That’s why you need a plan. Here are some questions to ask to start creating that plan:

  • What is the timeline for migration?
  • Who will be the individual from your company leading the migration?
  • Will the migratory investments be justified?
  • How soon do you need to see ROI on the migration?
  • What does the minimal viable product look like?
  • How necessary is it that all data, metadata, tags, and users are migrated?
  • What are migration hiccups that cannot happen?

Answer the above questions before you move forward. When you start working with a Drupal development firm, give them the answers to these questions. They’ll thank you and you’ll save a lot of project management/developer time, which equals money.

2. Audit your site from an organizational perspective

Knowing how your organization works and then communicating that to the development company will save a lot of back and forth questions. Here are items that you need to have ready before you talk to a company about a Drupal migration:

  • Identify what assets constitute the source site.
  • Identify which parts are to be migrated from source site.
  • During the migration, do you require enhancements on the site’s design/functionality, or will you retain the current design?
  • Does the target site require integrating with legacy systems that are difficult to work with (such as the third-party sources and customer databases)?
  • How will this migration streamline your organization’s workflow?

3. Audit your site from a technical perspective

The sooner you engage IT and your e-commerce team, the better. You’ll also want to include your marketing team on the conversations, because they’re the group that will actually use the product. Here are some key areas to identify from the tech perspective:

  • Identify the type of repository the source site uses for storing data
  • Evaluate how the source site structures non-content data
  • Research what tools other companies like yours have used to migrate their data
  • Talk to other companies to identify the best practices for minimal downtime and maximum data access
  • Identify hourly time commitment for IT and marketing to work directly with the migration company
  • Identify if there will be any customer relationship management (CRM) integrations for automation rules

4. Migrating Drupal versions still takes time

If you’re already on Drupal, great! You will probably still need to work with a migration company, but being on Drupal will save you time and money. However, here are a few things to consider to keep your budget intact:

  • Ensure all the modules used are available in an updated version so you can add them to your Drupal installation prior to data migration. If unavailable, you must disable them (from your source site) and redesign (this costs money)
  • It’s not possible to skip a Drupal version. For example, if you are currently on Drupal 5 and you are looking to migrate to Drupal 7, you’ll have to first upgrade to Drupal 6 and then to Drupal 7

And there you have it. You can work with any Drupal migration company on these questions to help your team transition to an open source CMS, within scope and without a headache.

Beginners to
Open Source

A collection of articles about how to get started in open source.

Jeffrey Wisard - Digital Marketing Manager at Drupal Partners
Jeffrey Wisard is the Digital Marketing Manager at Drupal Partners, a Division of Innoppl, Inc. Jeffrey specializes in making technical content readable, enjoyable and entertaining. When he’s not doing digital marketing, you can find him exploring his city, Atlanta, on a bike. Reach him @DrupalPartners.

3 Comments

Thanks for your post! Drupal migration is really a big check, especially for those who are not very computer literate. I made use of online converter that I've googled accidentally (http://goo.gl/ifUJ7x) and have zero regrets. All my website content was transferred to Drupal without intensive hands-on. Though there occurred some technical problems, mainly because my Drupal site had a lot of customized things. Anyway, this method is much cheaper and quicker than hiring a programmer.

Great article! Thumbs up to the author. Site audit is something that should be done as before the actual migration as well as on a regular basis after you have already migrated to Drupal (ex.module versions check, performance audit etc.) We provide such audits upon request for free. While migrating on a budget, we`d also recommend still keeping in mind quality. Consider developers that have passed Acquia Certification for Drupal developers.

Thank you for the article, but I would add those tips and tricks for migrating <a href="http://wearepropeople.com/">drupal site</a>, I read recently, who knows, it might be helpful for somebody.
So:
1. drush mreg
Quick and dirty way to register new Migration classes after you have already installed your migration.

2. drush ms
This is the fastest way to review the current state of migration classes. It also tells you if a class is registered or not (you either did not register or you did not correctly define the class in the info or migration.inc files).

3. drush mi --limit=5
The "mi" command is short for migrate import. Some imports can be rather large. While debugging, it's useful to use the limit flag with a number of records as a parameter to run a fixed sample of records. This can save a ton of time in identifying issues, while not waiting for an entire migration to complete.

4. prepareRow($row)
Each migration class has a prepareRow function that is extremely powerful. This enables you to alter row data before the mappings occur. This is also a critical place for debugging. Throwing in a drush_print_r($row) is an effective way to see mapping values for each record. Lastly, if you need to filter out rows, you can throw conditions in here and return FALSE to ignore specific rows.

5. drush mr
Even seasoned vets must iterate on migration classes during development. You will frequently be importing and rolling back. Leverage this command to rollback after running the import.

6. Data analysis
One key concept to this is mapping. You must map the existing data structures to new data structures (fields and content types). You will likely run into issues where things do not cleanly map to the new destination. Get questions in front of your client ahead of the development and as soon as possible. This can proactively help identify issues in scope.

7. Use of migrate version 2.6-rc1
An absolute must. A lot of polish has been applied to this version. Save yourself some hassle and just start with this version.

8. Use of linkchecker module
Migrations can be difficult to verify. You will likely be altering paths for images and links within the HTML of imported content. In doing so, download and enable the linkchecker module. Configure it to scan all content types found in your migration. Run the migration, and run cron until all links have been checked.

9. Use of the scanner module
This module enables you to verify the contents of content. If you alter HTML within prepareRow, you may want to spot check content for given conditions. But, spot checking large migrations are nearly impossible. Use of the scanner module enables a developer to check conditions within the imported content, instead of manual and error prone checks. It does have the ability to replace, but this should exist within your migration class to be applied in subsequent migration iterations.

10. drush mmsg
Due to the iterative nature of developing a migration, it's critical to see any output generated by a migration class. Use this command to review any output generated from a migration class. This helps with debugging fine grain issues you may run into, especially if customizations are made within the prepareRow function.

Creative Commons LicenseThis work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.