In 1 minute
- Decide what information you need before thinking about how to migrate it.
- Each data set needs a source and a person who validates it.
- Test with a representative sample before the final load.
- Plan the cutover: until when the old system is used and who validates the start.
Migration starts with a decision: what information the organization needs to work in the new system. Then you need to establish where it is, who knows it and how to check that it was loaded correctly.
Copying every available file can carry existing problems into the new environment. It is worth preparing the information and defining validation criteria before the load.
1. Take an inventory of your sources
Identify systems, spreadsheets and other relevant records. For each data set, write down an owner and how it is used in the operation.
| Information | Current source | Owner | Use in the new system |
|---|---|---|---|
| Customers and suppliers | To be completed by your team | To be completed | Identification and transactions |
| Products or services | To be completed | To be completed | Purchasing, sales or service delivery |
| Open transactions | To be completed | To be completed | Continuity of work |
| Balances and stock | To be completed | To be completed | Validated starting point |
| History | To be completed | To be completed | Reference or analysis, if applicable |
This table is a working tool for the reader; it does not represent any client’s data.
2. Decide what is migrated and what is kept for reference
Master data, open transactions and history have different needs. Migrating the full history may mean rebuilding relationships and rules that are no longer used.
The decision should weigh usefulness, quality and effort. It is also worth identifying which records must be kept to meet applicable obligations, with input from the relevant owner.
3. Check quality and consistency
Look for duplicates, incomplete fields, inconsistent codes and references that do not match across sources. Agree on a rule for each situation; do not delete or merge records just because their names look alike.
Prepare a representative sample. It should include both the usual cases and the exceptions that matter to the business.
4. Decide who validates each data set
A load can be technically complete and still be wrong for the operation. The person who knows the data must be able to review its content and the relationships that matter.
For stock or balances, define controls and reconciliations with the area owner. Technical review and functional validation play complementary roles.
5. Test before the final load
The test should check that the data loads and that it can be used in the intended workflow. For example: select a customer, record a transaction and look up the resulting information.
Log the errors and their fixes. If the source changes after the test, review which checks need to be repeated.
6. Plan the cutover
Agree until when work continues in the old system, how transition transactions are handled and who validates the start in the new environment.
Planning should cover backups, owners and the conditions for proceeding or reviewing the launch. The details depend on the project and the operation.
Checklist before migrating
- Each data set has a source and an owner.
- It is defined what is migrated and what is left out.
- Cleanup rules are agreed.
- A representative sample was tested.
- Relationships, totals and relevant use cases were reviewed.
- It is defined who accepts the load.
- There is a cutover plan and a way to handle open transactions.
- The people involved know the timing and their responsibility.
