How UK businesses can assess legacy systems, choose the right cloud migration approach, control costs, reduce risk, and move workloads without unnecessary disruption.
Legacy technology rarely becomes a problem overnight.
A server reaches end of support. Hardware becomes expensive to maintain. Deployments take too long. Scaling requires weeks of planning. A business-critical application depends on software that only a few people understand.
Eventually, the conversation begins:
Should we move to the cloud?
But that is only the first question.
The more important question is:
What is the right migration strategy for each application?
This is where many cloud projects go wrong.
Some organisations treat cloud migration as a large infrastructure-moving exercise. They assume every server should be copied to the cloud as quickly as possible.
That approach may move workloads, but moving a problem to the cloud does not automatically solve it.
An oversized server can still be oversized in the cloud. Poor access controls remain risky. Weak application architecture can still create performance problems. Unclear ownership and undocumented dependencies can still cause outages.
The goal should not be:
Move everything.
The goal should be:
Move the right workloads, using the right strategy, in the right order.
For UK businesses, the decision may also involve security, data protection, supplier arrangements, data transfers, cost governance, resilience, and long-term operational responsibilities.
This guide provides a practical step-by-step framework for moving from legacy infrastructure to a cloud environment with greater clarity and control.
Step 1: Start With the Business Case
Do not begin your migration by choosing a cloud provider.
Start with the reason for change.
Ask:
What business problem are we trying to solve?
Common answers include:
- Aging infrastructure
- Rising maintenance costs
- Hardware refresh requirements
- Slow environment provisioning
- Poor disaster recovery
- Limited scalability
- End-of-support operating systems
- Difficulty releasing new features
- A need for better analytics or AI capabilities
- High operational overhead
Each reason can lead to a different migration strategy.
For example, if your biggest problem is unreliable hardware, a relatively straightforward migration may provide value.
If your biggest problem is that application releases take months, simply moving the same virtual machines may not be enough. You may need automation, CI/CD, managed services, or application modernisation.
A strong business case connects migration to measurable outcomes.
For example:
Reduce environment provisioning from weeks to hours.
Improve recovery capabilities for critical applications.
Reduce dependence on aging hardware.
Support seasonal demand without permanently buying excess infrastructure.
Enable faster application releases.
Without clear outcomes, cloud migration can become an expensive technical project with no shared definition of success.
Step 2: Build a Complete Application Inventory
You cannot choose a migration strategy for systems you do not fully understand.
Create an inventory of your technology estate.
For each application or workload, record:
- Application name
- Business owner
- Technical owner
- Business criticality
- Operating system
- Database
- Hosting environment
- Data classification
- Major integrations
- User groups
- Peak usage periods
- Recovery requirements
- Licensing dependencies
- Current support status
Do not stop at listing servers.
A single business application may depend on:
- Active Directory
- DNS
- SMTP
- Shared file storage
- Scheduled tasks
- APIs
- Third-party services
- On-premise databases
- Certificates
- Licensing servers
- Batch jobs
This is why dependency discovery matters.
A web application may appear simple until migration day reveals that it depends on an internal SMTP relay, a file share, and a database located somewhere else in the network.
The application may technically start in the cloud while the business service itself fails.
Cloud migration is about moving services—not just servers.
Workload assessment should identify components, dependencies, performance requirements, security needs, and migration suitability before the move.
Step 3: Score Every Workload Before Moving It
Not every application deserves the same migration approach.
A useful framework is to score workloads across six areas.
1. Business Criticality
Ask:
- Does the application generate revenue?
- What happens if it is unavailable?
- How quickly must it recover?
- Can the business operate without it?
A customer-facing payment system requires a different migration plan from an internal test server.
2. Technical Complexity
Look at:
- Application age
- Code quality
- Unsupported software
- Number of integrations
- Database complexity
- Middleware
- Custom dependencies
The more dependencies and technical debt a workload has, the more carefully its migration strategy should be selected.
3. Data Sensitivity
Consider whether the application handles:
- Personal data
- Financial information
- Commercially sensitive data
- Employee information
- Customer records
UK organisations should understand their data-protection obligations and carefully assess cloud-provider arrangements, particularly where personal information may be transferred internationally.
4. Change Readiness
Ask:
- Is the application documented?
- Is there an active owner?
- Does the team understand how it works?
- Can changes be tested safely?
- Is the release process reliable?
An undocumented application owned by nobody is not a good first migration candidate.
5. Cloud Fit
Consider whether the workload could benefit from:
- Autoscaling
- Managed databases
- Containers
- Serverless architecture
- Managed storage
- Cloud-native monitoring
- Improved resilience
Some applications will benefit significantly.
Others may simply need to remain stable until they are replaced.
6. Timing
Migration timing can be influenced by:
- Hardware end of life
- Contract renewals
- Software end of support
- Licensing changes
- Business peak periods
- Planned acquisitions
- Major product launches
A technically simple migration may still be a poor choice if it conflicts with a critical business period.
Step 4: Choose the Right Migration Strategy
Once you understand the workload, choose the migration pattern.
There is no universal answer.
The most common strategies include the following.
Strategy 1: Rehost
Often described as lift and shift, rehosting means moving an application with relatively few changes.
For example:
On-Premise VM → Cloud Virtual Machine
Rehosting can be useful when:
- Speed is important
- The application is stable
- Major code changes are risky
- The system needs to leave aging infrastructure
- The organisation wants to migrate first and optimise later
However, rehosting should not become the default answer for every workload.
The UK National Cyber Security Centre warns that a simple lift-and-shift approach can preserve problems and recommends considering replatforming or refactoring where appropriate to gain more security and operational benefits from managed cloud services.
Best for:
- Stable legacy applications
- Predictable workloads
- Short migration deadlines
- Systems with limited change appetite
Watch out for:
- Oversized cloud VMs
- High ongoing compute costs
- Existing technical debt
- Continued manual operations
Rehosting moves infrastructure.
It does not automatically modernise the application.
Strategy 2: Replatform
Replatforming means making targeted improvements without completely rewriting the application.
For example:
Instead of moving a self-managed database directly to a cloud VM, you might move it to a managed database service.
Instead of maintaining local file servers, you might adopt managed object storage.
The application remains broadly similar, but some infrastructure responsibilities are reduced.
Best for:
- Applications that need moderate improvement
- Teams wanting managed services
- Workloads where a full rewrite is unnecessary
Benefits:
- Reduced infrastructure management
- Potentially improved resilience
- Better backup options
- Easier scaling
- More automation opportunities
Replatforming is often a strong middle ground.
It avoids the cost of rebuilding everything while still taking advantage of cloud capabilities.
Strategy 3: Refactor or Re-Architect
Refactoring means changing the application architecture to take fuller advantage of cloud capabilities.
This could include:
- Containers
- Managed Kubernetes
- Serverless functions
- Event-driven architecture
- Microservices
- Managed messaging
- API-based integrations
This strategy can deliver significant long-term benefits, but it requires more engineering effort.
Do not refactor simply because “cloud-native” sounds modern.
Refactoring should solve a real problem.
For example:
A customer platform with rapidly changing features and unpredictable demand may benefit from architectural modernisation.
A stable internal application that will be retired in 18 months probably does not.
Best for:
- Strategic applications
- High-growth products
- Systems requiring frequent releases
- Workloads with major scalability needs
- Applications central to future business plans
Risks:
- Longer timelines
- Higher engineering effort
- Greater change risk
- More testing requirements
Strategy 4: Retain
Not everything needs to move now.
Some workloads may stay in their current environment temporarily because:
- They depend on specialised hardware
- The vendor does not support cloud deployment
- They have complex dependencies
- The application is approaching retirement
- Migration risk currently outweighs the benefit
Retention is not automatically failure.
A good cloud strategy includes knowing what not to migrate yet.
Strategy 5: Retire
Some applications should simply be turned off.
During discovery, organisations often find:
- Unused applications
- Duplicate tools
- Old reporting systems
- Forgotten test environments
- Systems replaced by newer platforms
Migrating these systems would create unnecessary cost.
Before moving any workload, ask:
Does this application still provide enough business value to justify keeping it?
Retirement can be one of the fastest ways to reduce complexity.
Step 5: Build Your Cloud Foundation Before Migration
Do not migrate workloads into an unstructured cloud environment.
Create a secure operating foundation first.
This is often called a landing zone.
Your foundation should address:
Identity and Access
Define:
- User roles
- Administrative access
- MFA requirements
- Privileged access procedures
- Break-glass access
- Separation of duties
Use least privilege rather than broad administrator access.
Networking
Decide:
- Public versus private workloads
- Network segmentation
- VPN or dedicated connectivity
- Firewall controls
- Web application protection
- Environment separation
Logging and Monitoring
Centralise important information such as:
- Authentication activity
- Administrative changes
- Security events
- Infrastructure events
- Application health
Security guidance from the NCSC highlights governance, operational security, identity and authentication, audit information, alerting, data protection, and secure administration as core areas to assess when using cloud services.
Encryption and Secrets
Plan how data and credentials will be protected.
Avoid:
- Hardcoded passwords
- API keys inside source code
- Shared administrator accounts
- Unmanaged secrets in configuration files
Use appropriate secrets-management and identity services.
Backup and Recovery
For every important workload, define:
- Recovery Time Objective
- Recovery Point Objective
- Backup location
- Retention period
- Restore process
- Restore testing schedule
A backup policy that has never been tested is not the same as a proven recovery capability.
Step 6: Consider UK Data and Compliance Requirements Early
Security and compliance should not be added during the final week before production.
If you process personal information, review your obligations and cloud-provider arrangements early.
Questions may include:
- What personal data will be processed?
- Who can access it?
- Which legal entity are we contracting with?
- Could international transfer rules apply?
- Where and how is data processed?
- What processor and supplier arrangements are in place?
- How is access logged and controlled?
The ICO provides guidance on assessing international transfers and notes that cloud services can involve complex processing arrangements and global networks of providers and subprocessors. Organisations should review their specific circumstances and contracts rather than making assumptions based solely on a server region or provider brand.
For sensitive workloads, compliance and security decisions should involve the appropriate legal, privacy, security, and technical stakeholders.
The cloud provider's security capabilities do not remove your responsibility to configure and govern your own environment properly.
Step 7: Start With a Pilot
Do not make your most business-critical application the first migration experiment.
Start with one or two lower-risk workloads.
A pilot helps test:
- Migration tooling
- Networking
- Identity controls
- Monitoring
- Backup
- Runbooks
- Support processes
- Rollback procedures
The goal is not simply to prove that the application can run in the cloud.
The goal is to prove that your organisation can operate it successfully after migration.
After the pilot, review:
- What went well?
- What took longer than expected?
- Which dependencies were missed?
- Were the cost estimates accurate?
- Were support teams ready?
- Was rollback tested?
- What should change before the next wave?
Then improve the process.
Step 8: Migrate in Waves
Avoid treating migration as one massive weekend event.
Group workloads into waves.
Wave 1: Low Risk
Examples:
- Development environments
- Internal tools
- Non-production workloads
Use these systems to validate your approach.
Wave 2: Medium Complexity
Move applications with:
- Clear ownership
- Known dependencies
- Established testing processes
These migrations build organisational confidence.
Wave 3: Business-Critical Systems
Finally, migrate systems requiring:
- Deep testing
- Complex data migration
- High availability
- Multiple teams
- Carefully planned cutover
By this stage, your team should already have proven processes.
Experience should be built before criticality is increased.
Step 9: Test More Than “The Application Opens”
One of the biggest migration mistakes is performing only a basic functional test.
A login page loading successfully does not prove the service is ready.
Test:
Functional Behaviour
Does the application work correctly?
Performance
Does it meet expected response times?
Integrations
Do external and internal systems still communicate correctly?
Security
Are permissions, authentication, and secrets working as intended?
Backup and Restore
Can data actually be recovered?
Failover
What happens when a component becomes unavailable?
Operational Monitoring
Will the support team know when something goes wrong?
Business Acceptance
Can real users complete critical tasks?
Migration success should be defined before cutover.
Create measurable acceptance criteria.
For example:
- Response time remains within the agreed range
- Critical integrations work successfully
- Backup restoration is verified
- Security logging is operational
- Business users complete agreed acceptance tests
- Rollback is possible during the defined window
Step 10: Control Costs From Day One
Cloud is not automatically cheaper.
This is one of the biggest misconceptions in cloud migration.
Cloud gives organisations flexibility, but poor resource management can produce unexpectedly high costs.
Common causes include:
- Oversized virtual machines
- Idle development environments
- Unused storage
- Excessive data transfer
- Duplicate resources
- Lack of ownership
- No budgets or alerts
Build cost governance into the platform.
Use:
Resource Tagging
Identify:
- Application owner
- Environment
- Department
- Cost centre
Budgets and Alerts
Do not wait for the monthly bill.
Rightsizing
Review actual workload requirements instead of copying on-premise server sizes without assessment.
Scheduled Shutdown
Non-production environments may not need to run continuously.
Architecture Optimisation
Managed services, autoscaling, storage tiers, and appropriate capacity commitments may improve efficiency depending on the workload.
A useful cost model should separate:
- Migration costs — assessment, implementation, testing, cutover
- Transition costs — temporary dual-running, replication, connectivity
- Cloud operating costs — compute, storage, networking, backup
- Ongoing optimisation costs — monitoring, security, FinOps, platform operations
Cloud cost management is not a one-time exercise.
It becomes part of the operating model.
How Long Does Cloud Migration Take?
There is no honest universal answer.
Timeline depends on:
- Number of applications
- Data volume
- Dependency complexity
- Application ownership
- Testing requirements
- Compliance requirements
- Migration windows
- Network connectivity
- Amount of modernisation
A small migration may take several weeks to a few months.
A mid-sized environment with multiple integrations and hybrid requirements may take several months.
A major modernisation programme can take significantly longer.
The key point is this:
Server count does not determine migration complexity. Dependencies do.
Ten simple workloads may move faster than one undocumented application connected to five legacy systems.
Do not promise timelines before completing discovery.
The Biggest Cloud Migration Risks
Risk 1: Incomplete Inventory
You migrate the obvious application but forget:
- Scheduled jobs
- DNS records
- Certificates
- Shared storage
- SMTP
- Vendor connections
Solution:
Validate inventory data with application owners.
Risk 2: Moving Everything With One Strategy
A one-size-fits-all approach creates poor long-term outcomes.
Solution:
Choose rehost, replatform, refactor, retain, or retire based on each workload.
Risk 3: Ignoring Security Until the End
Weak IAM and poorly managed secrets can create serious risk.
Solution:
Build identity, logging, access controls, and security monitoring into the foundation.
Risk 4: Underestimating Data Movement
Large databases and file stores can take time to migrate and validate.
Solution:
Plan data migration separately from infrastructure movement where necessary.
Risk 5: Testing Too Late
Discovering integration problems during the production cutover creates unnecessary pressure.
Solution:
Test earlier and rehearse critical procedures.
Risk 6: No Rollback Plan
What happens if migration fails?
If nobody knows, the plan is incomplete.
Solution:
Define rollback triggers, responsibilities, timing, and communication before cutover.
Risk 7: Assuming Migration Is the Finish Line
After migration, teams may still need to:
- Optimise costs
- Improve monitoring
- Update security controls
- Modernise applications
- Remove legacy dependencies
- Train teams
Cloud migration is often the beginning of a new operating model—not the end of the project.
A Simple Migration Strategy Matrix
Choose Rehost When:
- Speed is the priority
- The application is stable
- Changes are currently risky
- You need to leave aging infrastructure
Choose Replatform When:
- The application can benefit from managed services
- You want lower operational overhead
- A complete rewrite is unnecessary
Choose Refactor When:
- The application is strategically important
- Scalability matters
- Frequent releases are required
- Existing architecture limits growth
Choose Retain When:
- Cloud migration is currently impractical
- Dependencies are specialised
- The workload is nearing retirement
Choose Retire When:
- The application no longer provides enough business value
- Another system has replaced it
- Migration would create unnecessary cost
Your Practical Cloud Migration Checklist
Before starting, make sure you can answer:
Business
☐ Why are we migrating?
☐ What measurable outcome should improve?
☐ Which systems matter most?
Discovery
☐ Do we have a complete inventory?
☐ Are dependencies mapped?
☐ Does every workload have an owner?
Strategy
☐ Does every workload have an appropriate migration pattern?
☐ Have we identified systems to retain or retire?
☐ Are workloads grouped into sensible migration waves?
Security
☐ Is IAM designed around least privilege?
☐ Is MFA enforced where appropriate?
☐ Are secrets managed securely?
☐ Are security logs and audit trails available?
Data
☐ Have data-protection requirements been assessed?
☐ Have cloud-provider contractual and processing arrangements been reviewed?
☐ Have applicable international transfer requirements been considered?
Operations
☐ Are monitoring and alerting ready?
☐ Are backups configured?
☐ Have restores been tested?
☐ Is post-migration ownership clear?
Delivery
☐ Has a pilot been completed?
☐ Are acceptance criteria defined?
☐ Is there a rollback plan?
☐ Are users and support teams ready?
Cost
☐ Are resources tagged?
☐ Are budgets and alerts configured?
☐ Are workloads rightsized?
☐ Is ongoing optimisation part of the plan?
Final Thoughts: Migrate With a Strategy, Not a Deadline
The best cloud migrations are rarely the ones that move the most servers the fastest.
They are the ones that make the business easier to operate afterward.
That requires more than copying infrastructure.
It requires understanding applications, mapping dependencies, choosing the right migration pattern, designing security early, testing properly, controlling costs, and preparing teams for a new operating model.
The smartest approach is usually:
Assess first. Prioritise second. Migrate in waves. Optimise continuously.
Do not ask:
How quickly can we move everything to the cloud?
Ask:
Which workloads should move first, which migration strategy creates the most value, and what must we put in place to operate them securely and efficiently afterward?
That question leads to better architecture.
Better timelines.
Better cost decisions.
And ultimately, a cloud environment that supports the future of the business instead of simply becoming a new location for old problems.
Frequently Asked Questions
1. What is the best cloud migration strategy?
There is no single best strategy. The right approach depends on each workload's business value, technical complexity, dependencies, data sensitivity, change readiness, and cloud suitability. A portfolio may use a combination of rehosting, replatforming, refactoring, retaining, and retiring applications.
2. Should every legacy application move to the cloud?
No. Some systems may be retained temporarily because of specialised dependencies or vendor constraints, while others may be better retired because they no longer provide enough business value.
3. What is lift and shift?
Lift and shift, or rehosting, generally means moving an application to cloud infrastructure with limited architectural changes. It can be useful for speed, but it may preserve inefficiencies that should be addressed later.
4. How long does a cloud migration take?
A small migration may take several weeks to a few months. Larger estates with complex dependencies, legacy systems, compliance requirements, and extensive testing can take several months or longer. Discovery should happen before committing to detailed timelines.
5. Is cloud migration always cheaper?
No. Cloud costs can increase when resources are oversized, idle environments remain running, storage grows without controls, or workloads are migrated without optimisation. Cost governance and regular review are essential.
6. What should be migrated first?
Start with low-risk workloads that have clear ownership and manageable dependencies. A pilot can help validate the migration process before moving increasingly business-critical systems.
7. What are the biggest cloud migration risks?
Common risks include incomplete inventories, missed dependencies, weak IAM, poor secrets management, underestimated data migration complexity, testing too late, uncontrolled costs, and unclear operational ownership.
8. Do UK businesses need to consider data-transfer rules when moving to the cloud?
Potentially, yes. Where personal information is involved, organisations should assess their specific cloud-provider and contractual arrangements and determine whether UK GDPR transfer rules or other obligations apply. ICO guidance provides frameworks for assessing these situations.
9. What should a cloud landing zone include?
A strong foundation commonly addresses account or subscription structure, IAM, MFA and privileged access, networking, logging, monitoring, encryption, secrets management, backup, recovery, policy controls, and cost tagging.
10. What happens after migration?
The work continues. Teams should stabilise workloads, monitor performance, test recovery, optimise costs, remove unnecessary legacy dependencies, improve security, and continue modernising applications where it creates business value.
Work with eSparks IT Solutions
Planning a project around this? We help businesses across the USA, UK, Canada, Australia and the GCC ship it. Explore our Cloud Computing services and portfolio, estimate your project cost, or book a free call.
Top comments (0)