Migration De Risking

The engagement

Unsung collaborated closely with the Head of Trust Services to re-platform 20 Root Certificate Authorities from an end-of-life vendor platform to a new strategic platform. This migration presented unique challenges as the required migration pathway was neither documented by the vendor nor supported through standard vendor processes.

Given the absence of established migration methodologies and the business-critical nature of the Root CAs involved, Unsung structured the engagement as a phased approach commencing with a formal feasibility study. This feasibility phase was designed to validate technical viability and prove the migration concept before committing to production execution.

Why feasibility was made a separate phase

The decision to begin with a formal feasibility study was the most consequential judgement in the engagement. The alternative, common enough in practice, would have been to commit to the full migration on the strength of a technical opinion that it ought to be possible, and to establish whether it actually was during production execution. With twenty business-critical root certificate authorities at stake and no vendor-supported path, that would have placed the organisation in the position of discovering an unworkable approach at the point of maximum exposure.

Separating feasibility gave the client a defined decision point. Either the method could be proven, in which case production execution proceeded against a validated procedure and a known risk profile, or it could not, in which case the organisation had spent a contained sum to establish that fact and could pursue an alternative strategy with the remaining budget intact. Both outcomes were acceptable, which is what made the phase worth commissioning.

The problem with an unsupported migration path

Where a vendor documents and supports a migration, the method is established, the risks are known and there is recourse if something behaves unexpectedly. None of that applied here. The pathway was neither documented nor supported, which meant the method itself had to be developed, and developed to a standard sufficient to be executed twenty times against production infrastructure.

Root certificate authorities compound the difficulty. They sit at the origin of the trust hierarchy, they cannot be taken out of service for convenience, and errors affecting them propagate to every certificate that chains beneath them. An unproven procedure applied to a root is not a manageable risk, which is precisely why the proving had to happen first and in isolation.

‍

The feasibility engagement delivered comprehensive technical validation and documentation that enabled the client to proceed with production migration activities with confidence:

• Delivered a fully documented, tested, and validated engineering methodology for platform migration encompassing all aspects of the migration process including prerequisite configuration requirements, detailed step-by-step migration procedures, and automated validation testing scripts.
• Established a repeatable, standardised process that enabled efficient, low-risk execution of production migrations across all 20 Root Certificate Authorities.

Establishing the technical baseline

The feasibility phase began with detailed due diligence across the source platform and the target: how key material was generated, stored and protected on each, how certificate structures were represented, and what would have to hold true for material to move between them intact. With no vendor documentation to work from, this understanding had to be established directly from the platforms, drawing on knowledge of certificate authority internals and hardware security module architecture rather than on published guidance.

Prerequisite configuration requirements

The methodology documented the conditions that must be satisfied before a migration is attempted, covering configuration on both source and target platforms, key protection arrangements and the state each system must be in. Prerequisites are frequently the difference between a procedure that works in a laboratory and one that works in production, because production environments vary in ways a controlled test does not. Capturing them explicitly meant each of the twenty production migrations could be verified as ready before it began, rather than failing partway through on an unmet condition.

Step-by-step migration procedures

Detailed step-by-step procedures were produced, specifying each action, its expected result and the verification to be performed before proceeding. This level of granularity was necessary because the procedure would be executed repeatedly against critical infrastructure, potentially by different personnel, and had to produce identical results each time. Procedures written at a summary level rely on the operator's judgement to fill the gaps, which is acceptable for a one-off exercise and unacceptable for a repeated one against production roots.

Automated validation testing

Automated validation testing scripts were developed to confirm that a migration had completed correctly, checking that key material and certificate structures on the target matched the source. Automating this was essential rather than convenient. Manual verification of certificate structure is slow, and it is subject to exactly the kind of inattention that repetition produces across twenty iterations. Automated checks apply the same scrutiny to the twentieth migration as to the first, and they produce a consistent record of the verification performed, which supports the assurance case as well as the execution.

A repeatable, standardised process

The output of the phase was a repeatable, standardised process enabling efficient, low-risk execution across all twenty root certificate authorities. Repeatability was the objective throughout. A method that works once demonstrates possibility; a method that is documented, tested, validated and automated where automation adds assurance can be executed twenty times with a predictable risk profile. That distinction is what allowed the client to proceed to production with confidence rather than with hope.

What this gave the client

The feasibility phase converted an unquantified risk into a known one. Before it, the organisation faced a business-critical migration with no supported path and no evidence it could be completed. After it, it held a validated methodology, a demonstrated proof of concept, and a clear view of the effort and risk attaching to production execution. That evidence base supported the investment decision, and it gave stakeholders concerned about the absence of vendor support something concrete to assess.

‍

The engagement presented fundamental technical challenges rooted in the complete absence of vendor support or documentation for the required migration approach.

Working without vendor documentation or support

Successfully proving feasibility required Unsung consultants to leverage extensive expertise across multiple technical domains including hardware security module architecture, detailed understanding of certificate authority platform internals, and development of bespoke scripting to address gaps in available vendor tooling.

Each of those domains was necessary and none was sufficient alone. Understanding how the certificate authority platforms structured their data established what needed to move. Understanding hardware security module architecture established how protected key material could be handled without compromising it. Bespoke scripting closed the gaps where no vendor tooling existed to perform the required operations. The engagement depended on holding all three together, which is why work of this kind is difficult to resource from generalist infrastructure expertise.

Developing bespoke tooling for a critical process

Scripting developed to operate on root key material carries an obvious burden: it must be correct, and its correctness must be demonstrable. Tooling was developed, tested and validated within the feasibility phase specifically so that its behaviour was proven before it was applied to production infrastructure. This is a further argument for separating feasibility from execution, since developing critical tooling under production time pressure invites exactly the errors the phase exists to prevent.

Proving a method to a sceptical audience

An approach the vendor did not support required stakeholders to accept a method with no external validation behind it. Documentation and testing were the answer. A methodology that is written down, executed against and verified by automated testing can be reviewed and assessed by others, which an expert assurance that the migration should work cannot. Producing evidence rather than opinion was what allowed the organisation to approve production execution against its own governance requirements.

Governance around a feasibility phase

The phase was run with the same delivery governance applied to production work: an agreed scope and success criteria defined at the outset, an actively managed RAID log, regular reporting against plan, and a defined decision point at its conclusion. Feasibility work is often treated informally, on the reasoning that it is investigative and its outcome uncertain. That is a mistake where the output will determine a major investment decision, because a study without agreed success criteria produces a conclusion that can be argued with rather than one that can be relied upon.

Phasing as a risk control

The value of the phased structure lay in what it did to the shape of the client's exposure. A single-phase commitment concentrates risk at the point of production execution, where the cost of discovering an unworkable method is highest and the options for responding are fewest. Splitting feasibility from execution moved that discovery point earlier, into a phase where an adverse finding was affordable and recoverable.

This is a pattern that applies well beyond this engagement. Where a migration path is undocumented, unsupported or simply unprecedented in the organisation's environment, a bounded phase that proves the method before committing to it is almost always cheaper than establishing the same fact during delivery. The apparent additional cost of the phase is generally less than the cost of a single failed production attempt.

The client proceeded to production migration on the strength of the validated methodology, executing across all twenty root certificate authorities against a procedure that had been documented, tested and proven before any production system was touched.

‍