Data Migration Risk Assessment
You can download a PDF version of this article here: Data Migration Risk Assessment Template
Virtually all business projects come with inherent risk, but data migration poses a vast web of complex challenges that can make or break your organization’s digital transformation – causing delays, unnecessary expenditure, and a slew of helpdesk requests.
The difference between success or failure often hinges on risk management, so before embarking on your journey, it’s crucial to understand which areas of data migration are most precarious.
In this guide, we’ll outline the key questions to ask ahead of time, allowing you to perform a thorough data migration risk assessment that will flag-up potential bumps in the road, helping to ensure a smooth transition as you upgrade your IT ecosystem.
Your Data Migration Risk Assessment Checklist
Listed below are the major points you need to consider when planning your migration project, and analyzing each one will help determine how much of a threat they are to overall success.
Scope clarity
Ambiguity is a huge stumbling block that frequently derails data migration projects, so it’s imperative to set clear, definitive goals from the outset. It’s easy to assume you have a simple, single objective in mind, i.e. migrate email to Office 365, and start mapping your journey from A to B.
But what about those archive journals and PST files? Do they need moving as well? Is there a danger your users will lose access to their data? Does this need to be addressed? Do we need to communicate to the users? If so, what, how frequently, and when?
Suddenly your proposal becomes all the more intricate, with ‘scope creep’ throwing your timelines and budget off course. Thus, it’s crucial to ensure all parties are on the same page, confident in the exact parameters of what is and what isn’t being moved.
Here’s what you need to clarify:
| Location of data | Where are you migrating from? |
| Type of data being migrated | What type of data is being moved from the location? |
| Data Filtered | Are you moving all the data? Some of the data? The last 7 years’ worth of data? Only data from active users? Only data of legal interest? |
| Out of Band Requirements | Atypical requests unique to your organization, i.e. the migration can only run at certain times of day, or you have multiple geographic locations. |
| Frequency of managing, monitoring and reporting | What cadence do you need to hit to keep on top of the project, how will this be achieved, and who will be responsible? |
Ultimately, it’s essential to make a clear, comprehensive plan and stick to it.
Understanding the source
There are multiple reasons why people take on data migration projects, and the target will be clearly defined, but it can be all too easy to overlook the source.
Understanding the infrastructure, scale and integrity of the source – reviewing its strengths and weaknesses – will help to architect a better solution to ensure a successful migration.
Here are the main areas you need to get a grip on:
| Integrity | Is data missing? Has something in the source caused data loss? |
| Performance | Are there any issues with retrieving items? A migration project will put the system under pressure, so it’s important to consider how this will affect usability. |
| Scale | How much data is moving? Are you moving < 1TB for 42 users, a journal archive with 172TB of content, or perhaps all data for all users – past, present, and undefined? |
| Where data travels | You need to understand the path your data is taking. Poor network latency between links, or constraints between output and throughput must be accounted for. |
| Geographic distribution | Enterprise organizations can have multiple offices, perhaps internationally, and their source environment (such as Enterprise Vault stores) may be spread throughout. Understanding all components of the source will help you design a more effective target environment, potentially helping to reduce overhead at the same time. |
| Resource ownership | Who owns the source resources you will be ‘touching’ in your migration? Consider deeper than the system you’re interfacing with and consider all the dependencies of that system. What process is needed when an issue impacting your migration is believed to be rooted in those resources? |
| Resource expertise | Who are the ‘experts’ of your source system(s), how do you get help when you need it, and (if unfortunately needed) what are the means of escalation if you’re not getting the attention you need from them? |
Understanding the target
Ensuring your target is properly configured, scaled and sized to accommodate a migration can spare errors, unnecessary failures and negative user experiences.
It’s important to consider the following:
| Size constraints | Is sufficient storage available? Have you configured all sizing considerations? Disk, SQL, Backup, replica? |
| User experience | Are there any known issues that could impact the end-users? What is their tolerance? Is communication to them needed? If so, how frequently and what content? |
| Performance | Is speed an issue? Depending on the cause you may have a drastic impact on your users. Perhaps the environment is not well suited to the anticipated size, or perhaps the endpoints are already busy and using them for a large data migration could make them seem unavailable periodically. It’s crucial to ensure everything is running smoothly before starting a migration. |
| Is it scaled appropriately? | Can the target accommodate the expanded use of the system or is additional environmental scaling needed to support the post-migration user base and usage? |
| Geographic distribution | Where will the data be stored? Do regional regulations (like GDPR) require you to separate your data into different regional data centers? How can the geographical needs of your project be used as a benefit in your migration? |
| Resource ownership | Who owns the target resources you will be ‘touching’ in your migration? Consider deeper than the system you are interfacing with and consider all the dependencies of that system. What process is needed when an issue impacting your migration is believed to be rooted in those resources? |
| Resource expertise | Who are the ‘experts’, how do you get help when you need it, and (if unfortunately needed) what are the means of escalation if you’re not getting the attention you need from them? |
Understanding the environment
Reviewing all points where the data of a migration will traverse through will help to pinpoint challenges or areas of architectural interest.
Make sure you have clarity on:
| Source resources | Generally considered the core resources of a source system, these would include the direct machine-related resources (such as RAM, CPU, and Disk) as well as the software and operating system utilizing those resources.
Source dependencies would also be up for consideration here. These would include SQL servers, File, Exchange servers, or any other resource the source solution you’re seeking to migrate touches to make it do what it does. |
| Intermediary environment | These would be all the dependencies of the solution you’re using to facilitate your migration. Perhaps this is just your workstation and a PowerShell script. There are many dependencies that a migration has revolving around the ecosystem it’s taking place in, and consideration of the components making up a migration solution are part of it.
Are your file servers up to scratch? Do you have any issues with SQL performance? Is your network highly utilized? Again, you have to have a firm grasp on your network path, the storage solution of your staging area, and any dependencies of your migration product. |
| Target resources | Similar to source resources, this is all the dependencies of the targeted system of a migration.
Depending on what you’re moving and where you’re moving to will depend on how many there are and whether you have the control to manage them or if they’re managed by a provider, as in migrations to Exchange Online. |
| Resource ownership | Now that you have identified all the resources in play for your migration, you need to consider who owns them and who needs to be communicated to in the event of an issue that implies those resources may be at fault. |
| Resource expertise | Commonly (but not always) resource experts are close to the owners. Know the experts in the areas you’re working within so that if something goes wrong you can ensure the correct people are working to fix it as promptly as possible. |
Collection and comprehension of constraints
Having a holistic view of a project’s constraints can help minimize their overall impact.
Reviewing each of these points will put you in a better position for a successful migration:
| Source health | Is it slow, struggling, not maintained? What challenges are there in the source and how do you expect those issues to impact your migration? |
| Computational resources | Do you have all the hardware, software, computers, servers, and disks to accomplish what you’re seeking in the timeline desired? |
| Staffing expertise | Do you have the requisite in-house skills to handle the migration? |
| User tolerance to issues | How are users likely to react to unforeseen problems? Identify stakeholders that need assurances and communicate with them accordingly. |
| Special considerations | Ensure you have clarity on atypical requests, and an agreed-upon process to deal with them. |
| Network utilization | Is the network within the source, through the migration pathway, and into the target moderately to highly utilized? Is it large enough How will the identified constraints impact your migration? |
| Target robustness | Do you have all the space you need to accommodate what you need to migrate? Is the solution scaled for the anticipated increased use? Can you handle all the migrated data once it’s migrated and being leveraged? Projects can stall for months if you don’t factor in space and budget. |
Ability to monitor and manage
It’s crucial to be able to pull regular metrics to determine progress (or lack thereof), who is ‘impacted’, and the status and performance of your data migration.
Can you dedicate staff hours for the duration of the project? Who will train them to be successful? Do you need external expertise to successfully manage the migration plan to completion?
| Holistic monitoring | Do you have a clearly defined process to regularly track the whole migration and its progress? How often will you be checking? Who needs this information? How tolerant are you to ‘downtime’ in your migration? |
| Knowing where to look and what to watch | Is your team familiar enough with the entire workflow to be able to identify points of failure or contention? Do they know where contention may exist and how to identify it? |
| Defining normal operations | How will you know what ‘good’ looks like? How many items per day do you anticipate migrating? How much volume per day? If you miss this target, how long will it be before more actions are required? |
| Identifying anomalous behavior | When something is ‘not right’, how will you identify actionable steps to make it ‘right’ again? How will you monitor to identify these issues? How will you know when an issue turns from anomalous to pursuable? |
This risk is commonly overlooked and highly impactful in my opinion. The basic question is, “Does your team have the time and expertise to be dedicated to pulling this project off for the duration of the migration, and if not, should you train them to sufficiently do this?”
Migrations take time, persistence, dedication and a small truckload of expertise to run smoothly. Most organizations go through the migration of important data sets a limited number of times, and the expertise to perform one is commonly gained from experience. Commonly, organizational experts that could pull off such a project are valued members of an organization that can add more value doing less tedious work.
Keeping a migration running daily is an important requirement if you’re going to meet your milestones. This can require dedicated experts for periodic checks multiple times a day. Issues identified have to be qualified into actionable remediation steps to resolve them. Who in the project team is going to assume this responsibility? Do they really have the time to sufficiently manage it? Can you risk regular multiple day outages in your migration due to infrequent monitoring?
Communication
Communication is key to any successful transition.
Frequent, consistent, clear communication at appropriate times and to the appropriate people will make a notable impact on the outcome of your data migration project.
| Consider the human element and Identify communication groups | Individuals react differently to change; some will require an email to explain expectations, others may require a more personalized approach. |
| Maintain a communication plan, and automate wherever possible | Map out what and when you’ll be communicating to users to ensure you alleviate helpdesk burden. See: Office 365 Migration: End User Communication Templates |
| Divergence communication | Ensure all messaging is unified to avoid confusion |
| Address identified ambiguity | Consider setting up an FAQ page on SharePoint |
Without adequate communication, your timelines can be thrown wildly off-track; projects can be postponed if there’s a substantial impact on helpdesk volume, meaning you’ll have to re-evaluate processes to find a better way of doing things. Such unexpected risks can be deal-breakers.
Dedicating time to the planning phase and understanding the potential risks of migration is akin to capturing the “Gotchas!” before they smack you in the face. And they’ll do exactly that if you don’t catch them upfront.