IT Tips & Tricks
5 Common (and Dangerous) Data Migration Mistakes
Plus a New Bonus Tip You May Not Be Expecting
By Ed Clark
Published 1 July 2016
Updated 21 March 2024
Do you have a data migration looming in your future? As you no doubt already know, moving data takes careful planning, exceptional management skills, and well-developed data migration techniques. Do you also know how to plan for possible setbacks and keep data safe during the transition?
We all know that doing a proper data migration is a complicated task — one that is often bogged down by various issues: You don’t have all the resources that you would ideally want, or you have a strict timeframe in which to get the migration done or the approvals you need take way too long from “those above.”
By keeping five six mistakes in mind, and preparing for them before your data migration, you can save yourself a lot of time and frustration — and your company lots of money, which just could lead to them giving some of that saved dough to you, in the form of a raise.
Mistake #1: Trusting That Your Backup Will Be There for You
“I have backups! We have so many backups! We always back up before we change anything around here. Heck, our cloud service provider backs up for us.”
I don’t doubt that you back up your data. The problem is that many (too many) IT directors trust backups that turn out to be unreliable or problematic — and they don’t realize it until it’s too late. Cue the hypothetical thought bubble: How often do you test those backups?
When was the last time you fully tested your backup system? When was the last time you did a test deployment of your backup in exactly the same manner as you would have to do it, should you actually lose some data?
Here’s where the mistake hides, like many, in plain sight. Many times, during the time-crunch of a data migration project, people are quick to back up the data and keep moving. Many times, people have to refer back to those backups, at least to recover some part of their data. Many times, the recovery mission fails, and only then do they realize that something is wrong with either the backup itself or with the
recovery system.
Does this even apply to those who are already using a public cloud-service provider?
Yes, though for a slightly different reason. You may find, during a test restore, that your backup settings were not what you thought. Someone could have changed them by mistake. Someone could have changed them “temporarily” and forgotten to reset them. Or some setting of your service provider may not be doing exactly what you thought it was doing. (We all know what happens when we assume something, eh?) A periodic test restore (at least a small one) could turn out to be revealing.
You may find, during a test restore, that your backup settings were not what you thought.
Of course, make a copy of your data right before migrating it. You want to be able to see everything as it was originally, on its original system, so that you can spot any corruption or anything that looks out of place. Make sure that you change as little as possible between the back-up phase, and the actual migration phase, so that you don’t lose any changes that you might make before the migration.
Oh, yeah, and test your backup. (Did I say that already?) In data migration, testing can save you untold hours and protect your reputation. So, run an actual recovery and see what happens.
Mistake #2: Getting Started Without a Solid Strategy
Planning is everything in data migration. A data migration checklist is crucial. It will help you prepare for possible issues along the way, and it can save you boatloads of time and money. Without a solid strategy or outline of the steps you’ll be taking, the migration process could be prone to data losses, security issues
and more.
Avoid migration mistakes with a checklist to keep you
on track.
Broadly speaking, what are the steps in a data migration?
They vary depending on your exact situation, but the following is an outline of the fundamental steps involved:
- Review the purpose of the migration and get familiar with the platform to which you will be migrating.
- Analyze the data to be migrated.
- Write out your strategy and the overall plan for implementation.
- Get buy-in on the plan from the applicable executives and other personnel who will be directly affected.
- Profile and organize the data.
- Check the data for quality and accuracy.
- Conduct data hygiene, including de-duping and archiving as needed. This would also be the time to prepare your links in advance, so as to save yourself a ton of time post-migration.
- Back-up the data one last time before migration and do a test restore of a sample of that data.
- Execute the migration.
- Qual-check the results.
- Correct any problems, including, fixing all the broken links. Note: If you smartly handled the links in advance, you wont' have this mess to deal with afterwards.
An entire article (if not a book) could be written about each of these broad steps. (Maybe I'll do that one day.) Just remember to develop a full plan — the glue that holds everything together. This way, if something unexpected happens (which it will), you can view the new situation in the context of your plan, which will help you avoid causing yourself a bigger problem as you adapt.
At the bottom of this page is a list of links to a few articles that go into more detail on some of the steps of data migration.
Mistake #3: Leaving Home Without
a Roadmap
A migration map will help ensure your data arrives safely at its final destination.
Look, you wouldn’t leave your house and try to fumble your way to someplace you have never been before without your GPS, right?
Okay, so why would you start a migration without a detailed report on all your files — where they are and what is connected to what? Knowing where your files are, what their purpose is, and what type of migration you’re doing will make the whole process much easier. It will leave less room for error too.
For additional safety (the ole “belt and suspenders”), consider making a separate copy of this report to refer back to. Keeping a copy somewhere else in case your main system fails may save someone’s bacon one day (and that someone may be you). This means that you have something external that maps out your file structure before the migration, so you have something to look back at during the migration itself. Then, if you get lost, you don’t have to stop for directions. (You may still need to make a restroom stop, though.)
There are several software applications available for cheap that can do this for you. One very simple way to do this, for Windows users, is, of course, to generate a report using CommandPrompt. However, this is a very simplistic program that just gives a “broad-strokes” view of your file structures.
Overall, find the tool that works best for you to generate a comprehensive view of your files, including all the links contained within them. (Hint: LinkReporter.com)
Mistake #4: Lack of Hardware, Software, and/or Network Preparation
Note: This section pertains to those who are hosting their own, whether on your network or your own private data center. If you are migrating to a public cloud service (such as SharePoint), you may skip ahead to Mistake #5.
“Huh? We have a lot of this stuff — particularly hardware — around here!”
Yes, but you are doing a data migration now. The rules change a bit. Consider the following.
Hardware:
Make sure that you have the allotted resources for your migration. When you’re doing a migration, you’re usually moving from an outdated or smaller resource to a larger one. Nonetheless, a good rule of thumb is to have at least 20% more capacity than you think you will need.
Has your new hardware passed a benchmark test?
Secondly, be sure that the hardware you’re migrating to has been tested and passed a benchmark test. Make sure that you’ve thoroughly tested it before the migration so that you don’t finish up your migration, pat yourself on the back, and then have something break five minutes later.
Software:
During the migration itself, be doubly sure that you’ve shut down any processes or applications on the software you’re using. Having other processes running in the background while you’re trying to do a migration can cause interruptions or complications in your migration.
Tip: If you’re using a Windows machine, check back periodically to be sure no pesky automatic program has started itself up while you weren’t looking. Yeah, these have been known to cause problems surreptitiously. (That means they’re sneaky.) You could spend many hours trying to figure out some weird phenomena, not realizing the source of the problem is something running that you didn’t notice.
You did everything right and your migration went smoothly. And yet you still have users floundering around and logging lots of complaints (sometimes disguised as support tickets). Want to know what happened here?
Network:
Last, but not least, you want to be absolutely sure you’re working with an open pipe. Make sure your firewall settings aren’t choking you from doing what you need to — but aren’t leaving you vulnerable either.
Also, if you’re going to have users on your network while you’re doing your migration, you want to be sure to throttle your own use, so that you’re not slowing down your users.
If you know you’re going to have users on at the time of your migration, plan for it. You can’t kick them out and lock the door (tempting as that may be), so you’ll have to be sure you’re allocating the proper amounts of bandwidth for both you and them, so as to not slow down any work for either of you.
Mistake #5: Not Having a Rollback Plan
Developing a rollback plan is one of the best data migration techniques and can help you save time and energy after the move. You may run into a few challenges while relocating data sets. Right now, you might be thinking you can simply go back and fix everything later. While that’s usually true, it can be a messy and inefficient way to work.
That’s why you need a rollback plan. Rather than waiting until after you’ve moved all the data to address issues, you’ll develop backups and a rollback plan to apply fixes along the way. For instance, one way to implement a rollback plan is to set checkpoints at specific stages of the migration so that you can run assessments on the data. If any transitions need to be rolled back, you can make the backups and deployments necessary to move forward.
Making sure you plan for all these things will keep you vigilant, and help make the other aspects of your migration run smoothly (“smoothly” being a relative term).
Not having a rollback plan will add extra work to your schedule and cause otherwise preventable disruptions after deployment. By adding one to your data migration checklist, you can make sure you’re equipped to address issues right away and create a better
final result.
Not having a rollback plan will add extra work to your schedule and cause otherwise preventable disruptions after deployment. By adding one to your data migration checklist, you can make sure you’re equipped to address issues right away and create a better final result.
Bonus: Mistake #6: Failing to Prepare Your Users in Advance
You did everything right and your migration went smoothly. And yet you still have users floundering around and logging lots of complaints (sometimes disguised as support tickets). Want to know what happened here? It’s your fault. This one is very simple in concept, but often not done well enough. It’s underestimated. You failed to anticipate what your most technology-challenged users may not know and also what they will try to do from their handicapped viewpoint.
Bonus Tip: Create short videos of you, showing the users what the results of the migration will be and what they need to know and do. Do this before your migration and get all users to watch your videos. If you have experienced a large-scale migration before that resulted in some confused users, you will see the difference this time.
Training the users ensures a more peaceful
IT department.
Summary
Some of these points might seem obvious, in hindsight. Yet these are the things that have bitten many an IT pro in the you-know-what. You should pay extra attention to these areas when planning a data migration, no matter how big or small. Making sure you plan for all these things will keep you vigilant, and help make the other aspects of your migration run smoothly (“smoothly” being a relative term).
Make sure your firewall settings aren’t choking you from doing what you need to — but aren’t leaving you vulnerable either.
If you’re interested in learning more about data migration tools and techniques that can help you move in the right direction, contact us today. Chat with us online at LinkTek.com or call a helpful Service Consultant at 727-442-1822 to get your questions answered.
Links:
- Four Things Before Starting Your Data Migration
- Planning for Migration: Eliminate the ROT
- Distributed File Systems for the Cloud: The Good, the Bad and
the Ugly - North of the 45th Parallel: Hours — Not Months — To Solve
Upgrade Issues - Australian University Completes Record-Breaking Data Migration
- How To Get Buy-In: Balancing Tradition and Novelty in Data
Center Migration - Cloud Data Migration Challenges: An Overview of Three Key Barriers
- Data Migration: Electronic Health Records
Links:
- Four Things Before Starting Your Data Migration
- Planning for Migration: Eliminate the ROT
- Distributed File Systems for the Cloud: The Good, the Bad and the Ugly
- North of the 45th Parallel: Hours — Not Months — To Solve
Upgrade Issues - Australian University Completes Record-Breaking Data Migration
- How To Get Buy-In: Balancing Tradition and Novelty in Data
Center Migration - Cloud Data Migration Challenges: An Overview of Three Key Barriers
- Data Migration: Electronic Health Records
Ed Clark
LinkTek COO
Feel free to share this article on your social media:
Recent Comments
- No recent comments available.
ChatGPT,
Gemini,
Claude and
Copilot
Leave a Comment