So we decided.
We have a new system selected.
But before we start using it, there are a few key business considerations that will affect how you transition to the new system. The basis is knowledge about the functioning of the old system and the possibilities of the new system as well as knowledge about the conditions of business functioning.
The use of this knowledge provides a chance for rational planning of the migration process and protects against chaos of spontaneous migration.
Below are some basic areas of analysis that will allow you to simplify migration as much as possible and reduce the risk of failure:
Cut the scope
Not all business products need to be migrated to the new system. Not all business products of the old system are available "in stock" in the new system, moreover, not all of them are needed to run a business after migration. Low-yield, rarely used products - it is easier to close them in the old system, move them to the archive than migrate to the new system. We focus on the "business core" and simplify data migration.
Fill the gap
How we will fill the functional differences between the old and the new system.
The new system does not always offer all the necessary functionalities to run our business. There is always a functional gap to fill in the new system and new ones may be needed in place of the excluded products. Migration to the new system cannot be a step backwards, it is to open up new business development opportunities - but not all ideas need to be implemented in time to launch the new system. We choose the most needed and the easiest to implement.
Static data migration
Will historical data be needed in the new system? Moving the history of operations, mapping the history of business events of individual migrated products is not a piece of cake, especially when they occupy non-trivial GB or TB. If it is possible - leave the old system in the "read only" state or use the data warehouse. And if we need to migrate static data - remember that it is a time-consuming process (data size!), So it is worth doing it before or after the dynamic operational data migration. We focus on ensuring operational business continuity and simplifying the migration process.
Migration model - how do we migrate to the new system?
The choice of migration method and time are other issues that need to be resolved.
The characteristics and scale of migrated business data determine the choice of migration method. When deciding on a business migration, we choose to open new business products and transactions only in the new one and gradual phasing out of operations in the old system - in accordance with the current rhythm of business. A technical migration choice is a one-time transfer of product and transaction status from a specific point in time. This operation can be performed manually / semi-manually with little support from IT tools, or automatically (when the scope of data to be transferred is complicated and too large) based on ETL tools dedicated to migration.
Migration time - When do we migrate to the new system?
The selection of the appropriate migration date is the result of the need to synchronize with our business partners, the rhythm of internal operational activities and the activity of our clients. We prefer days with low business and operational activity and we plan the migration itself so that it is the shortest possible process.
When taking subsequent decisions, we must remember that the continuity of business is a key issue, and the quality of migration is measured by the success of the business.
Of course, replacing the system with a new one is also a task for IT teams - but more on that in the next post.
Stay tuned!