Eight principles. Eight artifacts you can inspect.

The rule. We write characterization tests around the old code before we change a line, so every change is checked against how the system behaves today.

The mechanism. A characterization test records what the code does, not what it should do. It captures the quirks that other systems may depend on. Where coverage is thin, writing these tests is the first work in the project.

The artifact. A test suite that passes on the old code and must pass on the new. An excerpt from a real suite will appear here once the sample-repo work is published.

The rule. AWS Transform, OpenRewrite and coding agents do the bulk rewrites. A senior engineer reviews and signs every change before it merges.

The mechanism. Tools propose. Tests judge. A named engineer is accountable. Output that fails review is rewritten by hand, and no AI-generated change reaches production without that review.

The artifact. The review record on each diff: who signed it, which tests ran and what was changed by hand. See AI-assisted modernization.

The rule. We move one capability at a time behind a stable interface. Production stays up throughout.

The mechanism. The strangler pattern: put an interface in front of the old system, build the new capability behind it, shift traffic in steps, then retire the old path. Incremental modernization like this keeps the business running and makes each step small enough to review.

The artifact. A phase plan that lists each capability, its interface and the traffic-shift steps. The American National project used a phased migration with no big-bang cutover.

The rule. Each cutover ships with a tested rollback plan.

The mechanism. Old and new run side by side until the new one has carried real load. The rollback is rehearsed before cutover, not written after a failure.

The artifact. A rollback runbook for each cutover: trigger conditions, steps, owner and the time it takes.

The rule. We baseline performance, licence cost and open CVEs first, so the result is a number, not an opinion.

The mechanism. The baseline is taken in the assessment, before any code changes. The same measures are taken after each phase.

The artifact. A before-and-after metrics table per phase. A worked example from the sample-repo run will be added when it is published.

The rule. We land you on Tomcat, Spring Boot, Jakarta EE, Kubernetes and PostgreSQL, not on another proprietary platform.

The mechanism. The target for each application is chosen from open options, and the reason is written down. If an open target does not fit, the assessment says so.

The artifact. A target-platform decision record per application.

The rule. Every engagement starts with a fixed-price assessment. You know the scope and the cost before the migration starts.

The mechanism. The assessment produces the scope. The scope produces the price. We do not quote a price against an unknown estate.

The artifact. The assessment report, with a fixed price for phase one written next to the scope.

The rule. Support is lined up before go-live. AceMQ engineers support the new stack 24/7 from day one.

The mechanism. AceMQ is involved from the start of the project, so the people who will run the stack have seen it before it launches.

The artifact. A run plan and handover checklist: contacts, monitoring, escalation and rollback. See supported after migration.