Cloud Migration and DevOps for Secure, Resilient Systems
Cloud migration and DevOps for regulated organisations: an estate audit, a migration path chosen per workload, a secure platform built to NCSC principles, automated delivery pipelines and a cutover you can roll back.
Every release still needs a weekend, nobody has tested a restore, and the servers behind your core systems were built by hand. Thornacre’s cloud migration and DevOps service moves systems to the cloud or between clouds, builds new cloud platforms, and automates how they are tested, released and recovered. It is for regulated organisations that cannot afford an outage.
| Who it is for | CTOs, IT Directors, Heads of Data, CISOs, DPOs and COOs in any regulated organisation moving to, between or already in the cloud |
| The problem it solves | Systems on ageing servers or hand-built cloud accounts, with manual releases, no tested recovery and no record of why each system runs where it does |
| What we deliver | Estate audit, migration or new build on Microsoft Azure, CI/CD pipelines, infrastructure as code, monitoring, recovery design and handover |
| How we work | A discovery-style audit as the GDS Service Manual describes, then phased delivery with controls designed to the NCSC Cloud Security Principles |
| Regulations and standards | UK GDPR, NCSC Cloud Security Principles, Cyber Essentials, plus sector outsourcing and resilience rules |
What problem do cloud migration and DevOps solve?
Cloud migration and DevOps fix systems that are slow to change, hard to secure and hard to recover, wherever they run.
Cloud migration is the move of applications and their data from one host to another: from your own servers to a public cloud, or between cloud providers. DevOps is the practice of development and operations teams sharing one automated route from code change to live service.
The Office for National Statistics (ONS) Management and Expectations Survey found that 69% of UK firms with 10 or more employees used cloud-based computing systems and applications in 2023. The systems left behind are the hard ones: the line-of-business system and the database with twenty integrations.
Each persona feels part of it:
- The CTO or IT Director owns the exit date, the releases and the outage risk.
- The Head of Data needs every record to arrive unchanged in value and meaning.
- The CISO inherits a security burden that grows when a system is copied as it is or configured by hand.
- The DPO or Compliance Lead must show why each workload is hosted where it is, and that it can recover.
- The COO needs services to keep running through the move and every release after it.
The root cause is capacity, not skill. The engineers who run business-as-usual are also asked to plan the move, so systems get copied rather than improved and releases stay manual.
How does Thornacre deliver cloud migration and DevOps?
Thornacre delivers cloud migration and DevOps in six phases, each with a clear output. A system already in the cloud goes through them in place; a new build treats the migrate step as its first release. Platform and pipelines are built before anything moves, so cutover is a switch you can reverse. The diagram shows the fork for each workload.

- Audit and plan. Inventory every application, database, cloud resource and link to other systems, with its owner, recovery need and status: migrate, rebuild, archive or delete. Outcome: a decision matrix you approve.
- Choose the path. Decide per workload: re-platform or rebuild now, or move it as it is and modernise later. Outcome: a target architecture for each workload.
- Build the platform. Set up UK-hosted Microsoft Azure services with encryption, access control, monitoring and backups, all written as code. Outcome: a secure platform, ready before data or users arrive.
- Set up pipelines and environments. Create separate build, test, user acceptance, staging and live environments, with automated gates between them. Outcome: every change takes the same tested route to live.
- Migrate, test and rehearse recovery. Move and reconcile the data, run automated and manual tests, and restore from backup before owners sign off. Outcome: checked data and a recovery you have seen work.
- Cut over and hand over. Switch traffic with full rollback available, then shut down the old system. Outcome: a live service, with runbooks and paired releases until your team runs it alone.
The audit is the step most often rushed and the one that matters most: it is the one moment an organisation inventories its whole estate.
What do you get from cloud migration and DevOps?
You get a running cloud platform, the automation that keeps it stable after go-live, and the records that explain every decision.
- Hosting decision record. Each workload’s path and location, with the reason, ready for auditors and outsourcing reviews.
- CI/CD pipelines. Continuous integration and continuous deployment (CI/CD) means every code change triggers automated tests and security scanning, and failing code does not deploy. Small, frequent releases follow the GDS guidance on deploying software regularly.
- Infrastructure as code. Infrastructure as code is the practice of writing your servers, networks and services down as files under version control, like a recipe the platform is built from. Any environment can be rebuilt the same way, and every change is reviewed before it runs.
- Monitoring and observability. Observability is seeing from logs and metrics why a service is failing, not only that it is. Service health and security events are logged and alerted on, as the NCSC’s logging and monitoring guidance describes.
- Recovery design. Backups, failover and restore steps designed to each workload’s recovery need and rehearsed before go-live.
- Handover or managed hosting. Runbooks and training so your team runs the platform, or managed hosting with patching and dependencies kept current, as the GDS guidance on managing software dependencies sets out.
Which regulations does cloud migration help you meet?
A well-run cloud migration helps you meet UK GDPR security duties, NCSC cloud guidance and the outsourcing and resilience rules in your sector. Thornacre designs each platform to the NCSC Cloud Security Principles, 14 principles from data in transit to secure administration, and builds the Cyber Essentials controls into its code.
In the UK government’s Cyber Security Breaches Survey 2025, 74% of large businesses had a breach or attack in the past 12 months. Sector rules add their own:
| Sector | Regulation or framework | What it requires | How the service addresses it |
|---|---|---|---|
| Banking and payments | PRA SS2/21 | Outsourcing and third-party risk management, including data security, business continuity and exit plans | Workload register, exit route and a platform rebuildable from code |
| Insurance | FCA operational resilience (PS21/3) | Map and test important business services so disruption stays within impact tolerances | Dependency map from the audit, tested rollback |
| Private healthcare | Data Security and Protection Toolkit | Organisations with access to NHS patient data and systems must use the toolkit | Platform controls and evidence mapped to toolkit standards |
| Life sciences and pharma | EU GMP Annex 11 | Formal agreements with service providers; migration checks that data is not altered in value or meaning | Documented provider responsibilities and migration verification |
| Energy, water and critical infrastructure | NCSC Cyber Assessment Framework | Security outcomes for operators under the NIS Regulations 2018 | Design records, logging and monitoring mapped to CAF outcomes |
| Public sector | Cloud First policy | Public cloud by default; evidence the case for anything else | Hosting decision recorded per workload |
How do you choose between lift-and-shift and refactoring?
Choose refactoring where the system will live for years and time allows; choose lift-and-shift only when a deadline forces it.
| Criterion | Lift-and-shift | Re-platform | Refactor |
|---|---|---|---|
| Effort before the move | Lowest | Moderate | Highest |
| Security burden on you | Highest | Shared | Lowest |
| Ongoing maintenance effort | Often higher | Lower | Lowest over time |
| Best for | Expiring contracts, black-box apps | Standard CMS and web apps | Core systems with long lives |
The National Cyber Security Centre (NCSC) gives a plain warning in its lift-and-shift guidance: “Without additional work, your cloud system can end up with all the problems of the local system, together with some cloud-specific ones.”
- If the contract end date forces the move, lift first, then modernise in planned releases.
Expect tension: operations wants the exit date, security wants the NCSC principles, and compliance wants the outsourcing review first. A decision recorded per workload honours each priority somewhere.
When is cloud migration not the right choice?
Cloud migration is not the right choice when the real problem is the data or the application, not the hosting. Moving a broken system to the cloud moves the problem.
- If you are moving records off a legacy platform into a new data model, start with our data migration service.
- If the application is end-of-life, rebuild it through custom software development.
- If contracts or data-sharing agreements require data to stay on servers you control, check them before you plan a public cloud move.
The usual objection is “we will lose control of our own platform.” Infrastructure as code answers it: the platform lives in files your team owns.
Every week on unsupported servers or hand-run releases adds exposure, and a shrinking runway pushes every workload towards lift-and-shift.
Frequently Asked Questions
Can some systems stay on-premises during a cloud migration?
Some systems can stay on-premises while others move, so a cloud migration can run in stages. The audit records every link between systems, and the plan keeps those links working across both environments. Each hosting decision is documented with its reason.
Can you adopt DevOps for systems already in the cloud?
DevOps can be adopted for systems already in the cloud without moving them. Thornacre writes the existing resources down as infrastructure as code and puts releases through CI/CD pipelines with automated tests. Monitoring and a rehearsed restore follow, so the system becomes repeatable and recoverable where it runs.
Does moving to the cloud change our UK GDPR obligations?
Moving to the cloud does not remove your UK GDPR obligations: you stay the controller and the cloud provider becomes a processor. Thornacre keeps data in the UK, encrypts it at rest and in transit, and records how each control meets the NCSC Cloud Security Principles, including asset protection and resilience.
What evidence do we get for auditors and regulators?
You get a hosting decision record per workload, the infrastructure code, pipeline test results, restore tests, a control map against the NCSC Cloud Security Principles and migration verification records. Together they show what moved, where it runs, why, and how it is secured: the questions outsourcing and resilience reviews ask.
How do we start a cloud migration or DevOps project?
Start by listing every site, application and system link you run, on-premises or in the cloud, with its owner and how you would recover it today. Thornacre then runs the audit and planning phase with your team. Past migrations are on our case studies page, and related security work on cyber security.
If a cloud move is due or releases still need a weekend, ask us for a cloud and DevOps assessment. We will map what you run, what depends on it and the safest path for each workload. Email hello@thornacre.com to arrange it.
This page is general guidance only; consult your legal or compliance team for your specific requirements.