Step-by-Step Planning for Data Migration

Data migration takes many forms, including moving data between storage locations or mediums, changing the format of the data, and sharing or importing data between applications. It’s required when retiring a legacy system, introducing new apps or services, migrating to the cloud, or consolidating your data center.

Data storage can be a complicated beast thanks to the myriad ways data grows and integrates with various components of your IT infrastructure. A secondary goal of any data migration project should therefore be data management itself, reducing complexities introduced by application logic, customization, governance, and other entanglements.

Regardless of the destination of your data or the business drivers behind the migration, you’ll need to extract your data, modify it, and perform the actual data transfer. Detailed planning and risk evaluation are key before proceeding, especially as you are likely to handle some sensitive information.

Data Migration Scope

The first step is to determine exactly what data will migrate as well as the goals and business drivers for the migration. In order to avoid sneaky increases in the overall scope as you proceed, you need to be as specific as possible. To lay out the scope of the data, begin by describing:

Data location – Where is the data currently stored?

Data type – What type of data is it? Are there any special considerations with the format?

Amount of data – How much data is moving? Will you migrate everything from the current location or only a subset? What happens to the remaining data if you aren’t migrating everything?

Migration schedule – How quickly will this project move? Come up with key milestones and reporting dates to stay on track.

Dependencies – Are there any dependent datasets? Consider adding a contingency plan for any cross-object dependencies that are not discovered until you have already begun migration.
 

Involve Stakeholders

You must be in touch with relevant stakeholders for your data migration project in order to maintain business operations, ensure security, and avoid any unpleasant surprises along the way.

Users – The use cases and end users are a key consideration for your migration. You may need to schedule migration activities at specific times of day. Your destination may need to be designed with these users in mind when it comes to compliance, latency, or app integrations.

Responsible parties – Who is responsible for data ownership? Do compliance or infosec teams need to be involved? Who is accountable for tasks within the migration project itself?
 

Take Stock of the Data Source

It’s easy to pay the majority of your attention to the migration destination. After all, the source environment is likely due to be decommissioned. But there are key factors at hand before you send a single megabyte over the network.

Data status – Is all data accounted for? Any data leakage or missing data should be resolved prior to migration.

Platform performance – Run some baseline tests and carefully monitor system stress, as a migration can cause failures especially on already taxed legacy systems.

Network path – What are the original data sources? Where does it travel along your network? Measure and account for latency, throughput, and security measures that may impact your migration.

Decommissioning process – After data has migrated, what will you do with the source platform?

Data quality – Can your data stand to be cleaned or deduplicated prior to migration?

Sensitive data – Does any data fall under compliance or security standards that require additional measures?

Related resources – What stack is running the source storage platform? Take stock of physical/virtual stats like CPU, memory, and disk as well as any relevant software.

Dependencies – Is the source data using a specific platform like SQL, file servers, or Exchange servers?

Access methods – How will you programmatically access the data and metadata? If you require physical access, can you get to that hardware?
 

Destination Environment

Before you can begin migrating, you must configure and scale your destination environment. Considerations include:

Performance – Have you configured the target environment with future growth and performance in mind? Presumably you are anticipating a performance boost from the upgraded storage infrastructure, so carefully plan and test based on benchmarks taken when examining the source infrastructure.

Size and scale – You should right-size any cloud storage, as you can quickly provision additional space if needed. Any other media will require planning for data growth. Remember to consider backups and replication. Your destination environment obviously must have enough space for all incoming data, plus some overhead for good measure.

Physical location – Compliance measures and latency might play a factor in the geographic location of your data target. You may be able to choose a geo depending on your service provider, if using a hosted product.

Technical contacts – Who will own this environment? Who can you work with for assistance and troubleshooting?
 

Monitoring

Before, during, and after your migration you’ll need to keep tabs on the target and source storage environments. Migrations are not an easy task and you need to make sure you have the resources needed to guide the process through completion, including overcoming any problems along the way.

Monitoring software or services – What tools will you use to monitor the data source, target environment, and the path data will take as it is transferred?

Monitoring process – How often will you check your migration progress? How will you track the status? What stakeholders need to be kept informed?

Issue resolution – If something goes awry, how will it be remedied? At what point does someone need to step in and interfere with the migration process to resolve a problem?

Baseline performance – What kind of performance do you expect from the destination environment? How will you determine if it is out of bounds?
 

Testing and Clean-Up

Once your data migration is complete, you need to make sure all connected systems and apps are functioning properly.

Testing procedure – How will you test all related infrastructure and apps using this dataset?

Data integrity – Did all the data make the transfer? How will you guarantee that nothing was left behind? How will you monitor data quality should any defects be introduced?

System decommissioning – Plan the turndown of any legacy systems according to your company policies.

Throughout these steps, communication is also key, both with key stakeholders as identified in the migration plan as well as with end users. Don’t just let people know that the migration is occurring: inform them how it will impact their daily work, what will change after migration is complete (if anything), and when they can expect various steps to occur. A unified communication plan for all parties involved in the migration process helps avoid users turning to the support team with questions as well as with providing clear and concise information from a single source.

While data migration projects are complex endeavors, a clear plan will help you visualize and execute, hopefully with minimal unexpected issues along the way.