7-Step Data Migration Plan

Data migration is complex and risky — yet unavoidable for most companies' processes. Especially now, at times of mass transitioning from on-premises systems to the cloud, companies are migrating their data to or in-between Microsoft, Google, or AWS cloud storage. 

Regardless of the reasoning behind your data migration, the process and its pitfalls stay the same: downtime, data misplacement, data corruptions, losses, leaks, format incompatibilities, etc. In fact, Bloor’s data migration report shows that 84% of data migration projects overrun time or budget and 70-90% of migrations don’t meet expectations. 

Of course, the severity of failed migration consequences varies depending on the company’s size, the volume and importance of data, compliance implications, and more. But no matter if you are a small-to-medium or enterprise-sized company, losing data and money due to poor migration will take its toll one way or another. 

To help you avoid this scenario, we prepared a 7-step data migration plan to help ensure your data will be safe, sound, and smoothly transferred wherever you need it to. These rules apply to every type of data migration, but if you’re interested in migrating Google data specifically, read this article.

1. Assess and Define the Data to Be Migrated

The first step of any migration is to examine the data environment and set goals. A common mistake an IT admin (or another responsible person or team) makes is transferring all data they have to simplify the process. By doing so, they clutter the data storage, create confusion, and doom themselves or other employees to dealing with this mess later. 

The first step is to determine:

• Which data needs to be transferred and what for.
• Which data can be left behind and what to do with it.

For example, regarding cloud data, there are many reasons to migrate G Suite data, and knowing this reason helps you plan your further actions accordingly.

After you determined what and why you are migrating, the next step is to define: 

• Data format
• Data location
• Data sensitivity

This information will play a key role in how you approach data in the process. It will help you clarify what tools you need, what risks you may have, and what results you need to achieve.  

2. Decide on the Type of Migration

The type of migration you plan to perform depends on your company goals. There are two main approaches to data migration:

1. “Big Bang” Approach

During a “Big Bang” data migration, you set aside a window of time to perform the whole extract/transform/load (ETL) processing in one sitting. While it is happening, all your systems are basically “on hold,” which leads to your company experiencing downtime. The upside of this approach is the ability to deal with it quickly, in one time-boxed event. The downsides are the irreversibility and massiveness of problems if something goes wrong and the necessity to put all your data-dependent processes on hold, which always means money loss. 

2. “Trickle” Approach

As you could guess, this method is the opposite of the previous one. To trickle means to transfer data by parts of datasets, in phases. During this type of migration, both old and new systems function simultaneously. The upsides: You don’t have to stop all the operational processes to transport the data (it can go in parallel); also, it eliminates risks of potential interruptions. The downside is that this method is more complicated and usually requires more tools.

3. Define the Resources You Need

This step logically follows the previous ones. You need to meticulously analyze all the resources needed to tackle the project: the tools, the security mechanism to apply, the required knowledge and skills, and, as a result, the headcount, etc. Maybe you will need to outsource an expert, pay for a professional data migration software, pay for a backup solution, and so on. When you count the resources, you’ll be able to calculate how much it will cost you and how long it will take to transport your data. 

4. Set a Timeframe for the Migration

As you can see, every step goes naturally after the previous one. After you calculate the resources you need, you’ll be able to tell what amount of time it will take realistically. If you already have a deadline set by your stakeholders or C-level but the previous calculations have shown that doesn’t match the reality, it is time to present your arguments and propose a more doable date. 

If time is money and the deadline can’t be reset, think of how you can speed up the process. Often, it requires hiring an extra specialist or buying software that can automate the process. In the end, you should come out with a timeframe that is real and saves your company more money than it spends.

5. Assign the People Responsible 

Now it is time to assign the roles and responsibilities regarding migration within your company. Even if your company is small and the only person who can conduct and supervise the process is the IT admin or some other person, this person will most likely need information from other employees. It cold be the legal or security team, other employees whose data is manipulated, and so on. 

Even if you have only one or a few people who directly conduct the process, you must pinpoint everyone who can be involved in the migration somehow and what they are responsible for. This creates a clear picture and speeds up the process. 

6. Backup Your Data

We assume that most of the companies already have a regular daily backup. But if you don’t, it is time to create one, even if you aren’t planning on backing up your data regularly. Data migration is rarely a seamless process no matter how hard you try, and complications along the way can easily lead to significant data losses. One wrong click is enough to lose your business-critical data, so be sure to save the latest copy of all your data right before you migrate it.

7. Test the System and Migrate Data

When you have a prepared data migration framework with all the needed permissions, assigned roles, datasets to migrate, and qualified source and destination environments, it is time to test this system. To do so, you migrate a small portion of previously backed up data and see how it goes. And only if everything went well, you can finally start your migration by moving larger bits of data.