Principles of Evidence-Based Migration
These principles are the reasons behind the lifecycle: why we work from the actual source data before we map or code, map business meaning before fields, govern every decision, generate the program from the mapping, and prove the result against the source. Each one below states what we hold, why it matters, and what it changes in practice.
Principle 1
Data Is the Source of Truth
If it has business meaning, it is in the data. Documentation, interviews, and the data dictionary describe what the system was meant to do; the data records what it actually did.
Why it matters
In almost every legacy system the documentation is incomplete and out of date, and the people who knew the exceptions have moved on. The data is the only complete record of the business, and it is available on day one.
What it changes in practice
Once the project is underway, we analyse all raw source data, without assumptions and without filtering: every file, every field, every distinct value and where it occurs. The short discovery before commitment profiles the agreed files that set the price, not the whole estate.
That analysis is used throughout the project: to find candidate source fields for each target field; to verify that the source fields chosen make sense; to check that the defined logic covers every value that exists for those fields, not only the documented ones; to spot discrepancies that call for cleansing; and to generate test data (principle 9).
Principle 2
Business Meaning Before Technical Detail
Mapping is done in two passes: business first, technical second.
Why it matters
The costly gaps are business gaps: functionality, meaning, or granularity that one side has and the other does not, in either direction, including data the target needs that the source never held. They are cheap to decide early and expensive to discover in testing. Technical detail settled before those decisions is often redone.
What it changes in practice
The business pass maps the meaning of the source to the target model, with the people who own that meaning, and exposes the gaps (principle 4).
The technical pass (fields, keys, formats, transformation rules) starts only once those decisions are settled, so it is quicker and issues surface earlier.
Principle 3
Data-Driven Mapping
For every target field we ask: which source fields, from which source files, are needed to populate every occurrence of it?
Why it matters
A mapping that starts from the source lists what exists. A mapping that starts from the target fields ensures the target is complete and that every field has a traceable origin.
What it changes in practice
As each source field is chosen, we look at it through the analysis output to verify that its actual values fit what the target requires and to check them for discrepancies.
A discrepancy found here triggers a cleansing activity, not a surprise in testing.
The approach also shows what is left over: source files and fields that no target field uses. Without a decision, that data is lost at cutover. The options are made explicit: extend the target to hold it (a business gap), migrate it to another system, archive it, or drop it deliberately.
Principle 4
Expose Gaps Early
The process is built to surface business gaps between source and target as early as possible: during business mapping, not in user acceptance testing.
Why it matters
A gap found in mapping is a decision. The same gap found in testing is rework, delay, and sometimes a change to the target system that no longer fits the plan.
What it changes in practice
Gaps are not only functional. We look for functional gaps, where the target cannot represent something the business does today; missing values, where the target requires values the source never recorded; missing source data, where the target needs fields the source does not hold (they may exist in another system, be managed manually, or be derivable from source data); and granularity gaps, where source and target keep data at different levels of detail or aggregation.
Migration thereby tests the target design against business reality. The migration team becomes an early-warning mechanism.
Principle 5
Every Decision Is Governed
Not only gaps: every decision is recorded with who made it, when, and on what evidence.
Why it matters
Migration decisions change the meaning of business data. Months later someone will ask why a value is what it is. The answer must not depend on memory or on a spreadsheet nobody can find.
What it changes in practice
MCC keeps the participants of each mapping session and the author and time of every decision: mapping decisions, approvals, gap resolutions, rule changes.
A gap follows a governed path from finding to validation, and its outcome may be a rule, a change to the target, or a change to the migration process itself.
The same record supports reviews of the migration process itself, typically required in regulated industries, which examine not only the result but the soundness of how it was reached.
Principle 6
Separate Knowledge From Execution
Documentation ≠ Logic ≠ Code ≠ Execution.
Why it matters
When business logic lives only in code, only programmers can read it and it leaves when they do. When it lives only in documents, nothing guarantees the code follows it.
What it changes in practice
Requirements, rules, and the logic that implements them are kept as separate, linked elements in the mapping, each reviewable by the people qualified to review it.
The program is derived from them (principle 8), so the layers cannot drift apart.
Principle 7
Governed AI
AI as an assistant, not an authority.
Why it matters
AI is good at reading large analysis outputs, preparing sessions, and spotting patterns. It is not accountable for the meaning of your data.
What it changes in practice
Evidence stays inspectable. Recommendations are kept distinct from approved decisions.
Semantic decisions are made by people and governed like every other decision (principle 5).
Principle 8
The Program Is the Mapping
The migration program is generated automatically and consistently from the mapping data. What was decided and approved in mapping sessions is what runs.
Why it matters
Hand-written migration code drifts from the decisions it was meant to implement, and nobody can prove that it has not.
What it changes in practice
AutoCode generates the complete program for each unit from the business and technical mapping captured in MCC: the conversion logic, the balancing counters, and the counters and verifications defined in mapping sessions.
Changes are made in the mapping and the code is regenerated. Where the mapping is unchanged, the code is identical, across rehearsals and repeated migrations.
Rules are reused. MCC provides a set of predefined migration rules, and a customer-specific conversion or verification rule needed more than once is captured once as a customised rule and reused wherever it applies. Faster implementation, fewer errors.
AutoCode in MCC & ToolsPrinciple 9
Test Every Value, Once
A small sample that covers every distinct value is worth more than a large random one.
Why it matters
Random samples repeat the common cases thousands of times and still miss the rare ones. Time goes on noise, and the exceptions that break a migration stay untested.
What it changes in practice
From the analysis we know every distinct value of every source field and where it first occurs. Once mapping tells us which fields a unit uses, the Sample Extractor builds a source extract that contains only, and all, the records needed to cover those values, combined across fields where needed.
The result is a small test set in which every value is checked, with minimal effort.
Lifecycle: Test, Rehearse & MigratePrinciple 10
Preserve Traceability & Reproducibility
Any value in the target can be traced back to the source data, the rule that produced it, and the decision behind the rule.
Why it matters
Auditors, regulators, and your own users will ask where a value came from and why. A migration that cannot explain itself cannot be trusted, and one that cannot be repeated cannot be fixed.
What it changes in practice
Evidence, mapping, decisions, rules, generated code, executions, and validation results are linked in MCC in both directions.
Any unit can be regenerated from its mapping, and every validation result is kept with the version it proves.
Source evidence ↔ Mapping ↔ Decision ↔ Rule ↔ Implementation ↔ Execution ↔ Validation
How MCC keeps this in one placePrinciple 11
Prove the Result
A migration is not complete because the load completed. It is complete when what arrived is shown to match where it came from.
Why it matters
A successful load proves that records were accepted, not that they are right. The errors that matter are in the values.
What it changes in practice
Validation compares the items you define as critical against the source, at the depth agreed for each: counts per value or a full record-level comparison. Every discrepancy is explained.
What existed → what we decided → what we implemented → what was loaded → what we proved
Lifecycle: Validate & ProvePlanning a Complex Data Migration?
Let's examine the source environment, target objectives, and migration challenge.