Operational resilience
When should you security test a technology migration? Before it goes live, not after
Waiting until a technology overhaul is finished before testing it leaves new systems live and unchecked while the old ones are still running. How to align security validation to each deployment phase, and what it catches.
Security testing is the easiest thing to postpone during a major technology change, and postponing it is how new systems end up carrying live traffic before anyone has confirmed they were built securely. The reasoning behind the delay is sound. The assumption underneath it, that a migration finishes at a single point in time, usually is not.
The objection we hear most
It usually arrives in a single sentence: "We are in the middle of a big technology overhaul, so we will test once it is complete."
The reasoning is understandable. Testing an environment that is about to change feels like wasted effort. Budgets are committed to the migration itself, the project team is stretched, and there is a natural wish to test the finished article rather than a moving target.
The difficulty is that a migration is rarely finished in one moment. Servers, services and applications go live in waves, often months apart. Each wave is a production decision in its own right. By the time the programme is declared complete, much of the new estate has already been carrying live data and live users for some time, without anyone having confirmed it was configured securely.
How the gap opens
Consider how a typical infrastructure programme unfolds. A new server is built from a standard image, handed to an engineer to configure for its role, checked for function and brought into service. Nothing in that sequence asks whether it is secure. The engineer's job is to make it work, the project's job is to hit the go-live date, and security testing sits on the plan as a line item for later.
Multiply that across dozens of systems over several months and the result is predictable. When testing finally happens, it tends to surface a significant number of serious findings on systems that are already live: default settings left in place, services exposed that nobody needed, components that were out of date on the day they were deployed. Often these come as a surprise to IT leadership, because every system passed its functional checks and nothing appeared to be wrong.
Meanwhile, the systems being replaced are frequently still running. Decommissioning slips behind go-live on most programmes, so for a period the organisation operates two environments side by side: the old one, with its known weaknesses, and the new one, with weaknesses nobody has yet looked for. Exposure rises at exactly the point the programme was meant to be reducing it.
None of this reflects a careless team. It reflects a plan that treats security testing as a final step rather than part of each step.
A migration is not a single go-live. It is a series of go-live decisions, each one taken months before anybody plans to check the result.
Why testing at the end does not work
Leaving testing until the end creates four practical problems.
- New systems carry live risk from the day they go live. A server with default settings, missing hardening or unpatched components is exposed from the moment it takes production traffic, not from the moment the programme closes.
- Fixes cost more once a system is in production. Before go-live, a configuration change is a routine task. After go-live, the same change needs change control, a maintenance window, regression checks and sign-off from service owners who now depend on the system behaving exactly as it does.
- The people who built it have often moved on. Migration teams, contractors and integration partners are typically released once the work is delivered. Findings that arrive later land with a support team that did not make the original decisions and may not know why a setting was chosen.
- Two estates are harder to defend than one. Until legacy systems are fully retired, both environments need monitoring, patching and access control. A migration that runs long, as most do, extends that period.
Borrow the model software teams already use
Software development solved this problem years ago. Code is not written, shipped and then tested at the end. It is checked at defined points through the development lifecycle, so issues are found where they are cheapest to fix.
Infrastructure change can follow the same pattern. Instead of one test at the end of the programme, security validation is aligned to the phases every deployment already passes through.
- Build. Check the base image, operating system and default configuration before the system is handed to the team configuring it. The outcome is a clean, known starting point.
- Staging. Check the system after it has been configured for its role, including hardening, access and exposed services. The outcome is issues fixed while changes are still routine.
- Production sign-off. A final validation that the system matches the agreed secure baseline. The outcome is a documented decision that the system is ready to go live.
- Legacy retirement. Confirm that replaced systems have been switched off, disconnected and removed from access lists. The outcome is that the old exposure is closed, not just forgotten.
Each gate is short. None of them requires the whole programme to be complete. Together they mean that nothing reaches production unchecked, and nothing is left running once it has been replaced.
Where a programme introduces genuinely new internet-facing services, that phased validation is worth pairing with independent penetration testing before the service opens to the world. The two answer different questions: one confirms the system was built to the standard agreed, the other confirms it holds up against someone actively trying to break it.
What this changes for the business
Aligning testing to deployment phases does not add a large new workload. It moves existing effort to the point where it has the most effect.
The project team gets findings while they still own the systems and can fix them quickly. Service owners go live knowing what they are inheriting. IT leadership has evidence, phase by phase, that the new estate meets the standard it was designed to. And for organisations working towards Cyber Essentials Plus or ISO 27001, the migration produces audit evidence as it goes, so no audit becomes a last-minute rush.
It also gives the board a clearer answer to a question it should be asking of any major change programme, and one worth putting into the regular risk report: is our exposure going down as this progresses, or up?
What happens after the migration ends
A secure baseline confirmed at go-live is only accurate on the day it is confirmed. Settings drift afterwards through ordinary activity: an update reverts a hardening setting, a permission is widened for a project and never narrowed again. That is the same problem described in how misconfigurations cause breaches, and the answer is the same. Once the programme closes, the phase gates become continuous validation against the baseline the migration established, so drift is caught as it happens rather than at the next review.
Questions to ask before your next migration
If a technology change is planned or already under way, these questions will show quickly whether security is built into the programme or waiting at the end of it.
- At what point will each new system be security tested, and is that before or after it takes live traffic?
- Who signs off that a system is ready for production, and what evidence do they see?
- Is there a secure baseline that new systems are checked against?
- When will each legacy system be decommissioned, and who confirms it has actually been removed?
- If testing finds issues in systems already live, who owns the fix and how quickly can it be made?
If the honest answer to the first question is "once everything is finished", that is the part of the plan worth revisiting.
Threat Protect aligns security validation to the phases of your technology programme, from build through to legacy retirement, working alongside your project team and delivery partners with one point of accountability for the security of the change. See how continuous compliance keeps those checks running once the programme closes, or book a call to talk through a migration that is planned or already under way.
Further reading
Frequently asked
Questions readers ask before getting in touch.
- At each phase of deployment rather than once at the end. The practical gates are the base build, the configured system in staging, a production sign-off against an agreed secure baseline, and confirmation that the system it replaced has actually been switched off. Each gate is short and none of them requires the whole programme to be finished.
- Because a migration is rarely finished in one moment. Systems go live in waves over months, and each wave carries live data and live users from the day it is deployed. By the time the programme is declared complete, much of the new estate has already been in production unchecked.
- It generally does the opposite. Findings raised before go-live are routine configuration changes. The same findings after go-live need change control, a maintenance window, regression testing and sign-off from service owners who now depend on the system, which costs far more time than the check would have.
- Decommissioning usually slips behind go-live, so for a period the organisation runs two estates side by side: the legacy one with known weaknesses and the new one with weaknesses nobody has looked for yet. Confirming that replaced systems are switched off, disconnected and removed from access lists is part of the work, not an afterthought.
- Yes. Validating each phase against a secure baseline produces audit evidence as the programme runs, so the certification or surveillance audit draws on records that already exist rather than a reconstruction effort at the end.
Talk to us
Want to talk through how this applies to your company?
A 30-minute call with a senior advisor. No pitch. We will read your situation against what is in this piece and tell you the smallest sensible next step.