Migration Engineering

MIGRATION ENGINEERING

Knowing which assets are exposed is a different problem from changing them without an outage. Migration Engineering takes a scored register and turns it into an ordered programme of work with a rollback at every step. We sequence changes by dependency and change window rather than by score, deploy hybrid modes where a peer cannot move yet, and measure the performance impact on your workload before anything reaches production. The measurements come from your estate, because a handshake cost quoted from somebody else's benchmark is not evidence.

Request a demo The Theos Method

AutoPQC · roadmap illustration

tls-endpoints
→ hybrid ML-KEM-768
MAP
signing
→ ML-DSA-65
MAP
code-signing
→ SLH-DSA-128s
MAP
rollback-path
preserved
OK
performance-evaluation
planned
MAP

Illustrative migration plan · not current product output

Duration: [PLACEHOLDER: engagement duration, Migration Engineering]
Method: theos-method-v1.0
Surface: Chosen assets
Depth: Sequence · deploy · measure
Artefact: Ordered programme
Standards: FIPS 203 · 204 · 205

The starting point

A migration without a rollback is a wish.

The hard part of a post-quantum migration is not choosing algorithms — the standards did that. It is sequencing change across an estate that must not stop: which surface moves first, what the measured cost is on your workload rather than a benchmark, and what the path back is from every single step. Engineering is the discipline of writing those answers down before touching anything.

Scope

In scope, and not in scope

In scope

Sequencing: an ordered plan derived from dependency order, change windows and the readiness of each consuming system, not from score order alone.
Hybrid deployment: where a classical and post-quantum primitive run together, what each peer negotiates, and how the fallback behaves.
Rollback preservation: every step designed so the previous state remains reachable, with the rollback tested rather than assumed.
Performance proof: measured latency, throughput and resource impact on your own workload, captured before and after each change.
Standards mapping: which target primitive each asset moves to under NIST FIPS 203, 204 or 205, and why that target was chosen.
Verification: re-running discovery after each phase so the register reflects the estate as changed rather than as planned.

Not in scope

We do not operate your production systems. Your teams execute the changes; we plan them, prove them and verify the result.
Penetration testing of the migrated estate, and any form of adversarial validation.
Application rewrites and general modernisation work. We change cryptographic use, not architecture we were not asked about.
Source-code correctness review beyond the cryptographic call sites in scope.
Identity governance, cloud posture management, and endpoint security programmes.
Anything on a public blockchain and anything custodial. No wallet migration, no on-chain protocol work.

Surfaces

What we look at

01
Dependency order
What has to move before what. Verifiers before issuers, trust stores before leaf material, libraries before the services that call them.
02
Hybrid and interoperability
Peers that cannot move yet, the hybrid modes available in your stack, and the negotiated outcome when one side lacks support.
03
Rollback design
The recorded previous state for each step, the trigger for reverting, and a rehearsal that proves the revert works before the change ships.
04
Performance measurement
Handshake and signature cost, connection setup, CPU and memory impact, measured on your workload in a representative environment.
05
Change windows and blast radius
Which changes are routine, which need coordination across teams or with external counterparties, and what fails if a window is missed.
06
Post-change verification
Discovery re-run against the changed estate, so the closing register is observed rather than inferred from a completed ticket.

Scoring

How it is scored

Sequencing uses the same five dimensions as every review under the Theos Method: Primitive Fragility, Confidentiality Horizon, Reachability, Change Cost and Substitution Gap. Score sets the priority; Change Cost and Substitution Gap set the order in which that priority can be acted on. An asset with the highest score in the estate still moves late if its replacement primitive is not yet supported by a counterparty, and the plan says so rather than quietly reordering the list. The weights are published on the methodology page and are stated nowhere else.

Read the method specification

Deliverables

What you receive

01
Primary artefact
Remediation Sequencing Plan
PDF with a CSV work-item export
The ordered programme: each step, its target primitive, its dependencies, its change window, its rollback, and the owner who will run it.
02
Performance Proof Summary
PDF with the underlying measurement CSV
Before and after measurements on your workload for each change, with the environment, load profile and instrument recorded alongside every figure.
03
Exposure Register (CSV)
CSV, one row per asset
The register re-derived after each phase, so remediation progress is a measured delta rather than a ticket count.
04
Posture Attestation
Signed attestation, reference format TQ-PA-YYYY-XXXXXX
A closing signed record for the migrated scope on a named date under a named method version, checkable at Attestation Lookup.
05
Evidence Pack
Archive with a sha256 manifest
Configuration captures, measurement outputs and rollback rehearsal records for each step, hashed so an auditor can follow the change history.

Evidence

Evidence and reproducibility

theos-method-v1.0

Every performance figure states the environment it was measured in, the load profile applied, and the number of runs behind it, because a single sample is an anecdote. No figure from another organisation's estate is reused as a prediction for yours. Scores before and after each phase are pinned to theos-method-v1.0, so a change in the register reflects a change in the estate rather than a change in the rules. Reproducing our numbers describes how to repeat both the scoring and the measurement.

Reproducing our numbers

The standards floor

What the work stands on

Eight standards, runtime and custody lines sit underneath every engagement in the catalogue. Each card names the groundwork the estate needs for it to land, and the failure mode it retires.

FIPS 203

ML-KEM — key establishment

The module-lattice key-encapsulation standard. It replaces classical key exchange in TLS 1.3 handshakes, tunnel establishment and key wrapping — the surfaces where traffic captured today can be stored against a future decryption.

Groundwork: A runtime line that can load a post-quantum provider, stated per service rather than assumed estate-wide.
Risk retired: Sessions recorded now being opened later, once the classical exchange underneath them falls.

FIPS 204

ML-DSA — digital signatures

The module-lattice signature standard, the replacement path for RSA and ECDSA signing across code, documents and server authentication. During a transition it runs alongside the classical signature rather than instead of it.

Groundwork: A signing pipeline that can carry two signatures on one artefact for the length of the transition window.
Risk retired: A forged release or a forged server identity signed by an algorithm that no longer resists forgery.

FIPS 205

SLH-DSA — hash-based signatures

The stateless hash-based signature standard: the conservative member of the family, resting on hash-function assumptions alone. Its natural home is firmware and other signatures that must still verify decades from now.

Groundwork: Room in the artefact path for a larger signature than the lattice schemes produce.
Risk retired: A structural surprise in lattice mathematics taking both primary schemes down at once.

Policy

CNSA 2.0 — the dated timeline

The published NSA algorithm suite sets dates, not suggestions: post-quantum operational across national-security systems by 2030, exclusive by 2035. Even estates far from that perimeter inherit its dates through their suppliers.

Groundwork: A register the timeline can be laid against, asset by asset, rather than a single estate-wide guess.
Risk retired: Discovering a contractual algorithm deadline in a procurement questionnaire instead of in your own plan.

Transition

Hybrid establishment — classical + ML-KEM

The transition posture for key establishment: derive the session from a classical curve and ML-KEM together, so a flaw in either primitive alone leaves the session standing. Mainstream clients already advertise the combined group.

Groundwork: TLS 1.3 endpoints, and visibility into which peers negotiate the hybrid group and which quietly do not.
Risk retired: Betting the confidentiality of day-one traffic on a single primitive, new or old.

Runtime

The provider-capable runtime line

Post-quantum negotiation arrives through the runtime, and an estate pinned to older lines does not negotiate it. The version actually loaded per service is a finding in its own right, not a build-system detail.

Groundwork: Retiring the oldest runtime pins — or naming them in the register as accepted, dated exceptions.
Risk retired: One service negotiating hybrid while its neighbour, one pin behind, silently falls back to classical.

Tooling

Open post-quantum tooling, pinned

The open-source implementations the ecosystem tests against. Where they appear in an estate we record the exact build, because a reviewed library and a deployed library are only the same thing if their hashes say so.

Groundwork: A pinned build with its hash recorded in the register, not a floating dependency.
Risk retired: Drift between the implementation that was reviewed and the one that ships the following quarter.

Custody

KMS and HSM key custody

Where the keys actually live. Managed key services and hardware modules are adding post-quantum key types on their own schedules, and custody boundaries — who can wrap, rotate, restore — decide how a migration lands there.

Groundwork: Audit access to key inventories and rotation policy. Key material itself never crosses the boundary.
Risk retired: A replica, backup or recovery region migrating out of step with the primary it must mirror.

Inputs

Inputs and duration

Duration: [PLACEHOLDER: engagement duration, Migration Engineering]
Precondition: A current Exposure Register for the scope, from an Estate Inventory or a review in this catalogue.
Access we need: A representative non-production environment, read access to configuration, and a load profile that resembles production traffic.
People we need: An engineering owner per in-scope system, the change manager who books windows, and the platform team that operates the terminators or key stores.
What we never ask for: Private keys, production credentials, or the ability to make a change in production ourselves.
Handover: Each phase closes with a re-run register, a measurement summary and a rollback record before the next phase opens.

Questions

Questions we are asked

Do you make the changes yourselves: No. Your teams hold production. We produce the sequence, prove the performance impact in a representative environment, sit with the engineers during the change window, and verify the result by re-running discovery.
How do you decide what moves first: By dependency and change window, constrained by score. Verifiers precede issuers, shared libraries precede their consumers, and anything blocked by a counterparty or by hardware is placed where the block sits rather than where its score would put it.
What this engagement will not tell you: It will not tell you that the estate is now quantum-safe. It tells you which assets moved to which standardised primitive, what that cost in measured performance, and what remains. A migration completed today can be reopened by a future advisory against a primitive we adopted, which is why crypto-agility is part of the design and not a later phase.
What if performance proof shows the change is too expensive: Then that is the finding and it goes in the plan. Options are recorded: a different parameter set, a different termination point, hardware offload, or a deliberate deferral with the exposure stated. We do not report a measurement we would not want to defend.
Can we keep our rollback: That is a design constraint rather than an option. No step ships without a reachable previous state and a rehearsed revert, and a step that cannot offer one is escalated instead of attempted.

Signed · Verifiable

Every engagement in the catalogue ends with a Posture Attestation you can verify.

The attestation names the scope, the method version and the date, and anyone holding its code can check it on this site.

See the specimen Attestation Lookup

Three articles that go further

The scope conversation

Take Migration Engineering to a scope conversation

Tell us the estate you have in mind and we will walk through what this engagement would cover, what it would produce, and where its boundary sits — before anything is signed. If you would rather put questions in writing first, write to us instead.

Book a consult Request a demo Back to the catalogue