Know what the migration involves, before you commit to it.

Most failed migrations were decided before anyone knew what was in the codebase. The estimate came from a line count, the plan came from a slide, and the surprises arrived halfway through. The Migration Blueprint is the step that removes those surprises: we audit the system you have, define the system you want, and write down how to get from one to the other—with the risks named and the mitigations planned.

What you get

Two deliverables, both yours to keep and to share with anyone you like—including other suppliers.

Why the statistics matter

• Constructs and built-in functions used. This is what makes an effort estimate possible at all: what has to be supported, and what never appears in your code.
• The modules the application divides into. They define the order of migration, so work can be delivered and tested in increments instead of one risky release.
• Dead code. Code that is never reached is code you do not have to migrate, test or maintain—and on old systems there is usually a lot of it.
• Idiomatic patterns specific to your codebase. Recognizing them is what separates a mechanical translation from code your developers will accept as their own.

For Synon/2E codebases the Blueprint starts from a recovered function inventory rather than a raw line count — see Synon / CA 2E migration.

What is in the report

Section 4 is the one that decides whether the migration produces code you want to own. It documents the common patterns in your code and how each one will be translated, because idiomatic translation is a set of decisions taken in advance, not a hope.

How the engagement runs

• Determine why you are migrating. Cost, risk, hiring, scalability—the reason shapes every later decision, and it is worth half an hour of disagreement at the start.
• Examine the existing system. How it is structured, which constructs dominate, which modules it is made of, which code is unused, which parts of the standard library it depends on.
• Define the target architecture. Which environment, which languages and versions, which frameworks, which patterns and guidelines you want followed.
• Plan the move. How the same know-how is expressed in the new language, what can go wrong, how the UI is translated, what happens to the data, and in which order it all happens.

Clarity before action. The Blueprint gives you a roadmap before any code is touched—and if the honest answer is that the migration is not worth doing yet, the report says that too.

Evidence

David Nieper is a British designer and manufacturer of luxury women’s clothing, founded in 1961 in Derbyshire and employing over 250 people. We ran a Migration Blueprint on their systems; the case study describes what we found and what we recommended.

Download the David Nieper case study (PDF)

Where the numbers come from

The Code Insights report is machine output, not an opinion. Every figure in it is produced by parsing your source with the same language engines we license commercially — the ones that carry a test suite, a version number and a support contract — rather than by grepping the code or reading a sample of it. That is what you are paying for: an inventory nobody had to estimate.

You can read the engines’ own specifications on the languages we license, and how we make this kind of work estimable in the Chisel Method. If your language is not one we already cover, say so in the first conversation: the Blueprint depends on the engine existing, and building one is separate work with its own price.

What happens next

If you decide to go ahead, the plan becomes the contract for the work: Migration CodeCraft delivers the migration module by module, in the sequence the Blueprint defined, with the translated code and its runtime library handed over as each module is ready.

If you decide not to go ahead, or to go ahead with someone else, the two reports are still yours. They are written to be usable without us.

Download the Migration Blueprint brochure (PDF)