MCC & Tools
Migration Control Center (MCC)
Methodology made operational. MCC is the set of tools we built over years of migrations so that every step of our method leaves a record: what the data contains, what was decided, what was generated, what ran, and what was proven. It is not a product we sell on its own. It is how we take responsibility for a migration.
How the Tools Fit Together
One record of the migration, from the first extract to the last reconciliation.
The Mapping Workbench holds the single description of the migration. The Source Analyzer feeds it with evidence; the gap tracker and decision log keep it honest; AutoCode generates the programs from it; the Sample Extractor and the Validator test and prove against it; the Orchestrator runs it, cycle after cycle. Because every tool reads and writes the same record, specification, code, execution, and proof cannot drift apart.
- Analyze
- Map
- Govern
- Generate
- Sample
- Run & delta
- Validate
MCC | Source Analyzer
Source Analysis & Profiling
Know what the data contains before anyone decides what to do with it.
Specifications describe what a system was meant to hold. The Source Analyzer reports what it actually holds, element by element, and gives the mapping sessions facts to argue about instead of assumptions.
- profiles every data element of every source table and file: value distributions, empty and invalid values, rare codes
- finds data elements whose values appear related, and tables or files that appear related
- extracts representative keys for every distinct value, so an expert can open the real case in the source application and say what it means
- runs on complete, unfiltered extracts, so the same files later serve completeness verification; direct database profiling is available where extracts are impractical
What you get: gaps surfaced during analysis, while the target configuration can still change, rather than in acceptance testing or at cutover.
Lifecycle step: Analyze
MCC | Mapping Workbench
Mapping
The single source of truth for code, tests, and validation.
The Workbench connects source reality, business meaning, and the target model, and it is the only place the migration is defined. Everything downstream is derived from it.
- business mapping first: what the target needs, which source information can populate it, what is missing
- technical mapping after: rules for validation, transformation, missing values, and error handling, per target data element
- balancing counters defined for source and target at the agreed granularity, such as department, customer type, or date, and matched to each other
- what is mapped and what is not, what is used in the source and what is not, in one view
- markers for the data elements and logic points that need deliberate test coverage
What you get: a mapping the business can read and sign, that is also exactly what the programs will do and what the validation will check.
Lifecycle step: Map
MCC | Govern
Gaps, Actions & Decisions
Every finding becomes a visible decision with an owner.
A migration produces hundreds of questions nobody planned for. Govern keeps each of them connected to its evidence, its mapping elements, and the decision that closed it.
- a gap tracker: every gap categorised (missing target functionality, missing source data, representation differences, open business decisions), linked both ways to the mapping elements it affects, and followed to resolution
- action items with an owner on the source side, the target side, or the migration
- decisions recorded with who took them and when, linked to the rules and results they changed
- the evidence trail the customer, the auditor, and the next project phase can read
What you get: transparency during the project and traceability after it. Anyone who asks why a value is where it is can be answered from the record.
Principle: governed decisions
MCC | AutoCode
Code Generation
What was approved is what runs.
Hand-written migration code drifts from its specification the day it is written. AutoCode removes the gap: the approved mapping is the specification, and the programs are generated from it.
- generates the complete program for each migration unit from the approved mapping: extraction processing, transformation, target-file creation, counters, logging, and error handling
- predefined migration rules cover the common patterns; exceptional logic is added as reviewed snippets
- a change in a rule is a change in the mapping and a regeneration, never a hand edit of generated code
What you get: build time compressed, and a guarantee that specification, code, execution, and validation describe the same migration.
Lifecycle step: Implement- ReadsThe approved business and technical mapping, rules, and counters
- ProducesComplete, compilable migration programs per unit, with counters, logs, and error handling built in
- PrincipleDeterministic execution
MCC | Sample Extractor
Data Sample Extraction
Test the difficult cases on purpose, not by luck.
A random sample of a large source almost never contains the rare combinations that break a migration. The Sample Extractor builds samples from the analysis so that every value and every combination the rules must handle is present, in a file small enough to run in minutes.
- identifies record keys automatically and composes a sample that contains every distinct value of each marked data element
- covers combinations of marked elements, with t-wise coverage when the full combination set would be too large
- adds to the sample the source records that first reach a marked logic point during a test run
- produces small files with complete coverage, so a test cycle takes minutes rather than a night
What you get: fast test cycles with full coverage, and test data the business experts can review case by case in both systems.
Lifecycle step: Test, Rehearse & Migrate- ReadsSource extracts, the analysis results, and the test markers set in the mapping
- ProducesRepresentative sample files and the list of keys they contain, for review in the source and target applications
- PrincipleDeliberate testing
MCC | Orchestrator
Cutover Automation & Delta Cycles
The rehearsal is the runbook. The runbook runs itself.
A cutover is dozens of jobs with dependencies, a few manual checks between them, and a window measured in hours. The Orchestrator holds the whole sequence and executes it, in every rehearsal and on the night.
- the runbook as one structured list of tasks with dependencies, including the manual checks and notifications, so nothing lives outside it
- every task whose predecessors have completed starts automatically; completions are detected and the next ready tasks are scheduled
- live progress: status, start and end times, durations, and the total elapsed time, refreshed as the run proceeds
- any task or branch can be rerun; each run is parameterised by environment, delta number, extract date, and final-run flag
- every rehearsal is kept side by side with the previous ones, so the cutover duration is known before cutover night
- full and delta strategies: where the legacy keeps no change log, deltas are computed by comparing complete extracts, with delta logic defined per topic in the mapping
What you get: a cutover whose duration is measured in rehearsal rather than estimated, where nothing is forgotten at three in the morning and a failed step is rerun, not improvised.
Rehearse & migrate- Load
- Rehearse
- Delta
- Cutover
- ReadsThe job list with dependencies, environment parameters, and the delta logic from the mapping
- ProducesA timed, logged record of every run, with the counts and checks captured along the way
- In practiceHospital migration: cutover under eight hours
MCC | Validator
Validation & Proof
A migration is finished when it is proven, not when it is loaded.
A successful load says a process completed. The Validator says whether the right data arrived, in the right place, with the right values, and shows the evidence.
- completeness counters from the mapping, compared source against target at the defined granularity, including global counters summed across programs
- record-level comparison: the loaded data is extracted back from the target and compared with the source, field by field, under the approved rules
- every discrepancy listed with its explanation, never hidden in a total
- the evidence retained, so acceptance is a reconciliation rather than a feeling
What you get: acceptance based on a reconciliation that the business and the auditor can read, and a record of every difference and its explanation.
Lifecycle step: Validate & prove
Across the tools
Governed AI
AI assists. Decisions remain in human control.
AI works inside the method, on the evidence MCC already holds, and its output is a recommendation for expert review. Business and semantic decisions stay with people and are recorded in Govern.
- explains source-analysis results and points at anomalies and patterns
- prepares mapping sessions and suggests the questions to put to the experts
- reviews mappings and rules for inconsistency, and drafts rule descriptions
- summarises validation and reconciliation results
AI assistance + evidence + human governance + deterministic execution.
Technical Integration
MCC works on complete, unfiltered extracts of the source, fixed-width or CSV, from any system that can produce them, including mainframe databases where the record key or context has to be added by the extract. Direct database profiling is available where extracts are impractical. Target loading uses the target's own bulk interfaces, and the loaded result is extracted back for validation.
Want to See MCC on Your Data?
Let's examine the source environment, target objectives, and migration challenge.