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.
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 specificationDeliverables
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-XXXXXXA 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
sha256manifestConfiguration captures, measurement outputs and rollback rehearsal records for each step, hashed so an auditor can follow the change history.
Evidence
Evidence and reproducibility
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.
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.
Related reading
Three articles that go further
Discuss this engagement
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. If you would rather put questions in writing first, write to us instead.