Step 1: Define your “manufacturing process” in detail
A data migration project is no different to assembling a motor car.
Different suppliers submit materials and resources, often using a “Just-in-Time” approach and when you experience a stoppage or delay anywhere in the production line, the whole system suffers.
Critical to the “manufacturing process” of a data migration is a thorough understanding of the many activities involved, the assets they need to consume, and the order in which they need to execute.
For example – want to create an accurate metadata library or data dictionary? Then you need some output from your data profiling task. You can then go on to feed the gap analysis activity to identify anomalies between source and target.
By mapping all these dependencies to identify their entry and exit points, you stand a much better chance of coordinating each team member, supplier and stakeholder on the project.
Getting the whole process down on paper can help you reduce your anxiety and fear of being overwhelmed.
It also helps you prioritise critical resources.
For example, when you’ve mapped out the entire project as a series of tasks, milestones and resources, you can easily visualise how the performance of a single supplier or team member can impact the rest of the project.
Here is an example of a “manufacturing process” I created to help one client visualise all the tasks involved in their upcoming data migration project.
Unfortunately, I can’t share the components in finer detail (due to client confidentiality) but hopefully, it gives a feel for the depth required to model a complex data migration (this is actually a subset of the overall program!).
Step 2: Communicate (and defend) your project model
For one client, I created an incredibly detailed task dependency chart that took up about 5 A3 pages (moving from left to right). It showed each task, assigned to a resource, as a connected series of functions and deliverables, culminating in the final “product” of a successful migration.
One of the senior sponsors disliked this approach. They said I had over-complicated the project and created fear amongst management circles about the complexity of the project.
My response was to ask the sponsor where they would like to simplify the model by taking components out of the framework. As they examined the model, they tried to identify “blocks” of activity that could be removed. Each time they did this I countered with the downstream impact of their decision.
By the end of the exercise, the sponsor understood the “interconnectedness” of data migration activities. They appreciated far more just what goes into a migration project and why their support was so vital.
Get your first-cut data migration task model printed in as large a format as possible and get it up on the wall. Invite others to critique it.
Note that we’re not putting in deadlines and dates at this stage, just the physical activities in logical sequence. If people don’t agree with the functions of migration, it’s irrelevant what you put down regarding forecasts and deadlines.
Create a defensible model that outlines all the tasks and then start to figure out resourcing and timelines.
Step 3: Factor in your available resource (and establish the gaps)
Once you’ve got a reasonably clear understanding of your “data migration manufacturing process”, you now need to examine each task and identify what skills/resources will be required to deliver it.
Some functions, e.g. basic data profiling, can utilise junior staff, but more complex tasks, e.g. data quality rule discovery and transformation definitions, may require more advanced skills.
Only by mapping out your tasks in detail can you hope to consider what resources are needed at each stage in the migration.
It also helps you to understand what training is required so that, as in our manufacturing analogy, we don’t hit any bottlenecks in the overall process as people struggle to learn as they’re performing the activity.
What always becomes apparent during this process is where there are gaps in resource or skill levels. These shortcomings can often be filled internally using existing skills, but you may need to bring in specialist external support.
Next Steps:
It’s common to feel overwhelmed when faced with a significant and complex data migration, but there are ways to break out of the “fog” and deliver a successful project.
The key is to map out your intended process and then initiate a peer-review process until you have a solid, defensible strategy.
Remember that your plan will change as you learn more about your data landscape (both source and target). In particular, adapt to the outcome of your Impact Assessment or Landscape Analysis activities and continuously refine, communicate and update your “manufacturing process” for data migration.
To find out more about planning for your next data migration, visit our Data Migration Hub.