IT Tips & Tricks

Published 20 September 2014

Updated 26 January 2022

Four Things Before Starting Your Data Migration

And They May Not Be What You Think

This is not going to be your typical article on IT projects or data migration.

Ed Clark, LinkTek COO

Before we get into the four things, let me start by saying that this article assumes you already have the following basics in place: You have a purpose for the migration; an end result in mind; some kind of plan; and a decent staff of IT pros to carry it out.

I’m not writing a textbook here about migration. I’m not going to say “begin with the end in mind” and other abstract (boring) stuff you already know.

In this article, I use the term “failed” to simply mean any migration that doesn’t meet one or more important criteria such as deadlines, data integrity or budget — or just plain causes frustration above your usual frustration level. Also, this particular article is not a checklist of things to do to be successful in a data migration. We have a different article for that.

Thing 1

Even after reading my intro above, some of you still probably think I’m going to say something like “organization” or “planning”. Nope. I know you do these. But do you know how many IT project team leaders think they are organized and they aren’t, or at least not nearly enough? So what’s the thing that most IT Pros miss when planning a large data migration?

Answer: Imagination of bad things. That’s Thing 1.

Most of your failed data migration projects (heck, most failed IT projects of any kind) fail due to lack of imagination. Notice that I didn’t say “lack of planning”. (While this sometimes is the case, that topic is covered very well in a great eBook.)

Failed data migration projects (heck, most failed IT projects of any kind) fail due to lack of imagination.

Be willing to repeatedly rewrite your migration plan to include the avoidance of undesirable outcomes.

There is an insufficient amount of imagining the potential bad outcomes, so that you can prevent bad things from happening or at least be ready when they do.

In short, it’s not the old “failure to plan” (actually, some IT folks spend too much time planning); rather it’s a failure to look at all the ways the different systems are interconnected and then a failure to imagine what could go wrong. Once the outcomes are envisioned, you can make a plan that includes either avoiding or handling them.

One thing you could fail to imagine is one very common cause of losing data during a migration. See the “Bonus Thing” at the end of this article.

I’ll write another article, sometime in the coming months, with some tips on exactly how to imagine better. But, for now, for the sake of your time (and mine), I’m hoping that just raising your awareness of this area will help some, all by itself.

Thing 2

Conflict Avoidance. Once you get all your IT teammates on the same page, if you make changes or take actions with little coordination, you are going to have conflicts. And conflicts add time and frustration. (Don’t you have enough of these already?)

If you are organized, and there is sufficient communication within the project team, you increase your chances of getting this thing done on time and under budget. Look, large and even moderate-sized data migrations are rarely going to be easy. But, if all the team members know what the heck is going on and how their exact role fits into the overall plan, fewer issues are likely to arise.

If you make changes or take actions with little coordination, you are going to have conflicts.

Thing 3

The migration loop: If you’ve done everything right, the final step should bring you back to square one.

Alpha Testing. Yeah, the idea of “testing” is not new, but I would be remiss if I didn’t mention it. (I’m about to give you a twist on it, so keep reading.) But what’s this “Alpha” part all about anyway?

Well, borrowing a term from the software-development world, this is my way of saying that your first set of tests should be done on completely fake data (or unneeded copies of real data). Before you even touch any production data, you should have rehearsed the move you have planned. This will also help you with Thing 1. It will reveal some problems that you weren’t thinking of before. Then you can head them off in advance.

Now, here comes the new twist: How much alpha testing is enough?

Answer: If you haven’t run into a significant number of problems during your testing, you haven’t tested enough.

Thing 4

Beta Testing. (You probably saw this one coming.) This time, you take a small sub-set of the full data you will be migrating and you migrate that. Ideally, this would be a representative sampling taken from your full body of data.

Then you run the mini-migration all the way to the end, handling each problem as you go. You document each unexpected encounter and document how you overcame it. As you can see, in the end, it all circles back to “Thing 1”.

Okay, that’s the four things that I wanted to mention for now. I’ll mention more things, and go into more depth on things, in future articles. (I like the word “thing”.)

One thing you could fail to imagine is one very common cause of losing data during a migration.

Bonus Thing

Use LinkFixer Advanced^™.

Do you have questions regarding this article? Let us know in the comments below or e-mail us at: LinkMail@LinkTek.com

Feel free to share this article on your social media: