How to Document & Estimate Your Drupal 8 Content Migration Project

About to get your Drupal 8 content migration project off the ground? Still a bit hesitant?

No wonder, since just the perspective of:

1. setting up a thorough schedule, including all the major milestones and endless control points
2. deep analyzing the entire source data “overload”
3. setting up a detailed approach to content migrations
4. actually building the new website
5. but not before you've actually put together its Drupal 8 specific technical architecture (with all the Drupal 8 specific content types, modules, entities...)
6. testing till you... drop
7. then rolling back and testing some more

... can get quite discouraging.

So, let's simplify it! The entire Drupal 8 content migration process I mean! Let's break it down into multiple phases.

And in this blog post here I'll be pointing out to you, briefly, what goes into the:

1. content audit phase (along with an audit of all the features/functionalities)
2. documentation phase (including the project tasks assignment & checking off specific skills that your teams should have)
3. estimation phase

With a focus on security best practices to adopt throughout the process. Shall we dive in?

1. What Does “Migration” Even Mean in this Particular Context?

It comes down to moving data from one supposedly outdated website to a new one.

And in our particular context here “outdated vs current” translates into “an old version of Drupal vs a newer version of Drupal”. The newer one is Drupal 8.

2. (Re)Considering Your Content: 2 Predictable Decisions You'll Take

I'm sure you already predicted this step of critical importance when planning your migration to Drupal 8.

A content audit is, without question, a critical step to take, yet it shouldn't be a pointlessly overburdening one. By “pointless” I mean spending too much time creating the perfect migration path for... outdated content.

Content that you won't be using anyway once you migrate it to your (or your client's) new Drupal site!

And so, these are the 2 actions you'll most likely take after auditing your content:

1. you'll be pinpointing outdated, no longer relevant content on the “old” Drupal site, that you don't need to transfer onto your Drupal 8 site
2. you'll be restructuring the current information architecture and covert your content chunks into a more semantic data format (think outside the conventional HTML contexts and about using content as API on your future site)

3. Which Features Stay, Which Ones Go?

Undertake a “brutally honest” audit of your current site's features and functionalities this time:

• Which ones of them are your site's visitors actually using?
• Which ones of them are they constantly... ignoring?
• What brand should new functionalities you should implement on your new Drupal 8 website?

And speaking of this last question: you should start seeing your Drupal 8 content migration as a site rebuild, as well.

You'll be actually setting up, from the ground up, the proper environment in Drupal 8 with new functionalities added to! That should “welcome” and seamlessly accommodate the transferred content.

4. Assigning Your Drupal 8 Content Migration Project to the Right Team(s)

At this stage of the migration planning process — the documentation stage — 3 people, standing for 3 district roles in your team, should get co-opted:

1. a project manager/analyst
2. a marketing manager
3. a developer

With a focus on the first 2 of them.You'll see why in a minute.

Now here are the skill sets and hands-on experience to look for when selecting these key people to work on your project:

• the assigned project manager (or/and the analyst) should also be a competent information architect; well familiar with the usability principles that the content to be migrated need to comply with
• they marketing manager (or senior content editor) should be the one deciding precisely what content gets migrated and the form it should take
• your assigned teams (and this calls for the Drupal developer's expertise), should be well aware of each system's capabilities — your current sites and your future Drupal 8 site's  capabilities — and thus get a straight answer to the question: “What content is, indeed, transferable and how precisely?”
• also, it's recommended that your team gain an in-depth understanding of your site's traffic and of its usage by the time this Drupal 8 content migration process starts
• and also, one of them should have the necessary know-how and configuration management experience to set up &export content types and fields

As you can see, the Drupal developer's contribution to this documentation & analysis phase is minimal. And this because his technical expertise will be most needed in the next step of the process (when the data gets actually migrated).

It's then that he'll be... “stealing the show”.

Nevertheless, as already mentioned, his/her input should be asked for to make sure that content can be transferred to the target system. To ensure feasibility of the entire data migration process from a technical standpoint.

5. From “It Depends...” to a Rough Time Estimate 

That “Well... you know... it depends...” answer causes a lot of (legitimate) frustration, doesn't it?

But there must be some sort of guidelines to help you give a time estimate, right? Even if a very rough one.

And there are:

Node/User/Taxonomy migrations           1-5 content types     6-10 content types     11+ content types

Initial analysis                         16-24 hours          32-40 hours             48-56 hours

Content type creation & export           16-40 hours          40-80 hours             8 hours/type

Configuration Grouping                   16-24 hours          24-40 hours             24-40 hours

Content migrations                       16-40 hours          32-56 hours             8 hours/type

Testing                                  24-32 hours          40-56 hours             8 hours/type

Additional Migrations

 
Files & media migration                       32-56 hours

Other entity types                            16-40 hour per entity type

Migrations from non-Drupal sources            16-40 hour per source type

Once all the project management aspects of your migration are clearly defined, the process itself should go smoothly, according to the detailed schedule.

Also, as you can easily see, numbers state the obvious: the heavy weight of the entire Drupal 8 content migration process gets lifted right at this planning and documenting stage.

Implicitly, the developer will start reusing the same fields (or some pretty similar ones). Which leads to convenient code and configuration overlaps.

6. Make User Data Security Your Top Priority

And this should be the case when undertaking any web development project after all.

Looking on the bright side of a migration process: it's a one time project!

Therefore, at the end, you just disable all the custom modules you will have written precisely for this data transfer and leave no traces, no security breaches behind.

Yet, common sense precautions and best practices are definitely required! Especially when it's user data (along with other sensitive data) that you're handling.

Here are some critical safety measures to apply:

1. ensure that no user data (XML files, database dumps etc.) gets accidentally sent around via emails (or any other unsecured form)
2. ensure your database and development server infrastructures are upgraded to the latest standards
3. ensure that your git repository isn't (God forbid!) public
4. consider clearing your development database off all the email addresses and user accounts still lingering there

As you can see, these are nothing but common sense safety measures. Make sure your entire Drupal 8 content migration process complies with them and take no risks.

And this is how you, plan and put together your migration strategy, select and prepare your teams and give a close-to-accurate time estimate!

What do you say: what other key steps to take/best practices to apply at this stage of the process should I have mentioned here?