The new system has been chosen and the old one has to switch off. The hardest part is not configuring the new one. The hard part is proving that exactly what was supposed to move actually moved, and that the old system can now be closed down.
A migration does not usually build new functionality. The substance of the work is data moving from one model into another, and that is analysis work: which field corresponds to which, under what rule it is transformed, what is done with missing and contradictory data, and how the result is checked to make sure it adds up.
For the bulk build of transformation and load pipelines we bring in a partner who works from the same mapping and the same quality rules. The mapping, the quality rules and the reconciliation checks stay our responsibility, so the basis for acceptance does not depend on who wrote the scripts.
A failed migration looks technical, but it is almost always a question of substance. Two systems understand the same concept differently: a customer is a contract in one place and a person in the other, a date is the time of the transaction in one place and the time of the entry in the other, and one system has three statuses where the other has seven.
These are questions of concepts and models, and they are settled before the first load. The same chain of artefacts repeats across all our services: source, rule, check. In analysis it is requirement, control and evidence. In migration it is field, transformation rule and reconciliation check.
Source and target fields mapped, with transformation rules and exceptions.
Findings with volumes, impact and decisions.
A summary of each run: what moved, what got stuck, what was fixed.
A list of checks with their queries and expected results, repeatable after the switchover as well.
Steps, times, the people responsible, decision points, and the conditions for stopping.
What was decided about history, exceptions and missing data, and why.
All deliverables are handed over in editable formats. The reconciliation checks can be re-run a year later, when somebody asks where a number came from.
A migration is a period when real data moves more than usual and exists in two places at once. Part of the work is therefore about who sees which data in test environments, when a masked or reduced copy is used, and how long test copies are kept.
The other part is the trace. Which data was moved, when and by whom, which rule changed it, and on the basis of which check it was accepted. That trace is also what an auditor or a data protection officer asks for, and it is easier to collect while the work is happening than afterwards.
The founding analyst has 13+ years of practice with systems, data models and interfaces in banking, telecom, IT consulting and logistics. Those are exactly the fields where bringing data together, quality rules and reconciliation are daily work, because a number has to add up even when it is asked about a year later.
Qualification: BCS Foundation Certificate in Business Analysis. Working languages Estonian and English.
We write in Estonian first. The pieces below have not been translated yet and open in Estonian.
Each of these is a starting point; we settle its scope in conversation and fix it in a written offer. The steps can be taken separately, or one after another in a logical sequence.
A fixed-scope written assessment, before the decision or before the tender. It answers the question of what data you are dealing with, what is in order in it, and what has to be resolved before the switchover.
What it includes:
The mapping and rules layer you can load from and check against. This is a deliverable that can be handed to any implementer.
What it includes:
Driving the substance of the whole migration, from mapping through to acceptance. One person accountable, holding the rules, the test migrations and the checks together.
What it includes:
Support during the cutover week and after it, when decisions have to be made quickly and in writing. Suits you when the implementer is in place but the data side needs an independent head.
What it includes:
Write down which system the data moves from and which it moves to, and by which date the old one has to close. We talk the scope through and send a written offer. We reply within one working day, and the first discussion is free.
