Data Migration Services
Move important data with evidence, reconciliation and control.
Plan, cleanse, transform, validate and reconcile data migrations while preserving auditability and business confidence.
Discuss this requirement →Start with the environment, risk and required outcome.
Plan, cleanse, transform, validate and reconcile data migrations while preserving auditability and business confidence. Namandla Consultants begins with evidence and recommends a proportionate engagement rather than a generic technology package.
Connected expertise for the wider environment.
Clear steps. Visible decisions.
Why data migration derails system replacements
It is the workstream most often underestimated and it is the one that determines the go-live date.
Scope assumed rather than decided
How much history moves? All of it is expensive and slow. None of it removes your ability to compare year on year. That is a business decision and it has to be made early, because everything else follows from it.
Source data worse than expected
Nobody profiled it. The migration is designed against the schema, and the data contains twenty years of workarounds: statuses that do not exist in the documentation, mandatory fields left blank before they were mandatory, records with encoding artefacts from a system replaced in 2009.
Mapping treated as a technical task
Where the old system has one status field and the new one has three, somebody has to decide how they map. That is a business decision that gets handed to a developer, who makes a reasonable guess, and the guess is discovered after go-live.
One attempt
A migration executed once, over a weekend, with no rehearsal, is a plan with no evidence behind it. Trial loads are what turn the estimates into facts.
No reconciliation
The load completed, therefore it worked. Nobody counted.
How a migration should run
1. Profile the source
What is actually in there, per field. Distinct values, null rates, patterns, orphans. This is where the surprises are found and finding them here is a fraction of the cost of finding them during the third trial load. Covered on data quality.
2. Decide scope
Which entities, how much history, what gets left behind. Options for history include full migration, a summarised load or leaving the legacy system available read-only for a defined period. The last is frequently the cheapest correct answer and it is rarely proposed.
3. Map with the business
Field by field for the entities that matter, with the transformation rules and the default values agreed and written down. Where a value in the old system has no equivalent in the new one, the business decides what happens.
4. Build the conversion
Extract, transform, load, with every rule implemented as documented and re-runnable from scratch.
5. Trial load
Into a copy of the target. Then again. Three to five trials is normal on a substantial migration. Each one produces a defect list and a measured duration, and the duration is what tells you whether the cutover window is realistic.
6. Reconcile
Record counts per entity, control totals on financial values, and a sample compared field by field. Signed off by the business rather than by the migration team.
7. Cutover
Final load with the source frozen, reconciliation repeated, business verification, then go-live. With a rollback point until verification passes.
8. Retain the source
Read-only access to the legacy system for a defined period. This is what makes the history-scope decision affordable, and it is what answers the query nobody anticipated.
Reconciliation
The part that turns a migration into something defensible.
Record counts per entity, source against target, with the difference explained rather than tolerated. Records deliberately excluded should be counted as excluded, not simply absent.
Control totals on anything financial. Outstanding balances, transaction values, stock quantities. These have to agree exactly and where they do not, the difference is investigated rather than rounded.
Field-level sampling. A random sample compared in full, plus a targeted sample of the awkward cases: records with unusual statuses, maximum values, missing fields, non-standard characters.
Business sign-off on the reconciliation, not on the migration. The migration team confirming its own work is not a control.
Keep the evidence. Auditors, and anyone querying an opening balance in eighteen months, will ask. Retained reconciliation output answers it in minutes rather than reconstructing it.
What Namandla delivers
Source profiling. Scope and history strategy. Mapping workshops with the business, documented. Conversion build, re-runnable. Trial load cycles with defect tracking and measured durations. Reconciliation design and execution. Cutover planning with rollback. Legacy retention arrangement. Evidence pack retained.
Remote delivery nationally. Onsite in Gauteng for mapping workshops and cutover support.
Common questions about Data Migration
How much history should we migrate?
A business decision, made early, because everything else depends on it. Full history is expensive and slow. Two to three years covers most operational and comparative needs.
The option most often overlooked is keeping the legacy system available read-only for a defined period, which lets you migrate a modest amount of history and still answer the occasional question about 2016. That is frequently the cheapest correct answer and it removes most of the pressure from the scope decision.
How long does a data migration take?
For a mid-market system replacement, eight to twenty weeks of migration work running alongside the wider project. Profiling and mapping is a third of it, build is a third and trial loads and reconciliation are the rest.
The variable is source data quality and business availability for mapping decisions, not technical effort. Migrations that resource the mapping workshops properly finish faster than ones that treat mapping as a developer task and rework it after the trial loads.
Why do we need multiple trial loads?
Because the first one always finds things. Three to five trials is normal on a substantial migration, and each produces a defect list and a measured duration.
The measured duration matters as much as the defects. A cutover window planned at eight hours against a load that actually takes fourteen is discovered on the Saturday, and by then the decision is between going live on bad data or standing the business down. Trials replace that estimate with a fact.
How do we know the migration was correct?
Reconciliation: record counts per entity, exact control totals on financial values and field-level sampling including the awkward cases, signed off by the business rather than by the migration team.
A load completing is not evidence. The failure mode is not a crash, it is a subset of records silently rejected or transformed incorrectly, which is only visible if someone counted. Retain the reconciliation output, because it is what answers an auditor or a query about an opening balance later.
What about legacy data migration from a very old system?
More profiling and more mapping effort. Old systems accumulate workarounds: statuses not in the documentation, fields repurposed for something else, encoding artefacts from an earlier replacement.
Extraction can also be the constraint where the source has no supported export and the documentation is gone. In those cases reading the underlying data structures directly is sometimes the only route, and it needs to be verified carefully against what the application displays, because the two do not always agree.
Can we migrate in phases?
Sometimes. Entity-by-entity phasing works where the entities are genuinely separable. Where transactional data references master data that has not moved yet, it does not.
The more common workable phasing is by business unit or site, where each runs on the new system independently. That requires both systems live in parallel for a period, with a decision about how reporting spans them during the transition, and that reporting question is usually underestimated.
When is a migration not the right approach?
Where the data is genuinely no longer needed operationally and a read-only archive would serve. Migrating twenty years of history into a new system because it exists adds cost, extends the timeline and imports old data problems into a clean system.
The alternative is a defined archive with a documented access route. It is cheaper, it is faster and it is generally what people actually need, which is the ability to answer an occasional question rather than to transact against 2011 records.