“It is the economy, stupid”.
Don’t lose sight of the large picture. The migration project is not an asset that returns a dividend, it is just sunk cost. Do everything you can to minimize expenditure. At the same time know the value your project bring to the company. Your project might be expensive, but NOT doing your project is even more expensive.
Control the scope
As a project manager, you have only one really effective ways of controlling the cost of the migration project and that is the scope of the migration. Controlling the scope of the project takes a few shapes, however.
You can try to question some of these points.
- Do we need the data at all, or can we live without it
- Do we need the data to be present immediately after the migration
- Do we need the data fully integrated with the new system
- Do we really need perfect data or can we live with exceptions and special cases
Do we need the data at all
Obviously there needs to be a demand for the data, otherwise, it is just a wasted effort to migrate. This is just the classical view of the scope.
Do we need the data fully integrated?
The old legacy system has a lot of data and you often only need part of it.
Most data in a system exist in different versions, often you can just take the last current version and forget about the rest. Audit logs are an integral part of most systems, but not a user story that is often used. If you can keep a copy of the old data you will often be able to piece together an audit log by combining data from the old and new system. This means you need to move a lot fewer data.
Another reduction in data could be gained from examining historic information. Often the data in the system relates to a long-standing relationship with the customer, but do you really need all the historical information in details. Perhaps you can make an aggregate of the historical information and transfer that or just move parts of the data.
Do we need the data present at once?
If you do not need the data present immediately after the migration, you get the option to use human labor to input the data manually after the migration has occurred.
Automation is often the preferred solution, but don’t be afraid to hire an army of humans if they can solve the problem better. If migrations could be solved by 20 unskilled people manually input data in the new system, that solution would be worth considering.
But automating a task after the migration rather than before is often drastically easier and will save you headaches. When writing rules for a migration they often have the form of “IF you detect situation A, then move the value of field B to the new field C”. Depending upon your project you might find it difficult to specify exactly the condition that must apply. In extreme cases, the situation might never occur, so you write code for situations that never materialize.
After the new system is up and running it is much easier to estimate what data remains to be moved since the source system is now static.
Perfect Data?
You have to view a migration project as a system SLA.
You are building a migration engine that will transfer data of the old system into the new system. How much of the relevant data you move automatically will determine how hard the project is.
- 99% migration is easy
- 99,9% migrations are hard
- 100% migrations do not exist given sufficiently complicated systems.
Do not aim for 100%