Cloud migration can improve:

• flexibility
• resilience
• remote working
• scalability
• collaboration
• security
• access to modern services

But moving systems to the cloud is not automatically an improvement.

A poorly planned migration can leave a business with:

• higher costs
• broken integrations
• worse performance
• weak permissions
• confusing ownership
• unnecessary virtual machines
• new security risks

The right question is not:

“How do we move everything to the cloud?”

It is:

“Which workloads should move, what should replace them, and how do we design the destination properly before we migrate anything?”

That is the difference between a cloud migration and a cloud strategy.

1. Start With the Business Reason

Do not begin by choosing Azure, AWS or Google Cloud.

Start with:

Why are we doing this?

Common goals include:

• replacing ageing servers
• supporting hybrid work
• improving disaster recovery
• reducing dependency on one office
• increasing scalability
• retiring unsupported software
• improving collaboration
• strengthening security

Microsoft’s Cloud Adoption Framework begins in exactly this way: define business motivations and measurable outcomes before designing the technical solution.

A good objective might be:

“Remove dependency on the office file server and support secure access for remote staff.”

A poor objective is:

“We should be in the cloud because everyone else is.”

2. Inventory What You Actually Have

Before moving anything, build a proper inventory.

Include:

• servers
• applications
• databases
• file shares
• user accounts
• network dependencies
• printers
• licences
• backups
• integrations
• scheduled tasks
• security controls

Many cloud projects fail because an apparently simple system depends on something obscure.

For example:

application → local database → mapped drive → old service account → physical licence dongle

Move only the application and the business process breaks.

Microsoft’s migration guidance similarly stresses workload assessment, compatibility and dependency validation before production cutover.

3. Decide the Future of Every Workload

Do not automatically “lift and shift” everything.

For each system, decide whether to:

• retire it
• retain it
• replace it with SaaS
• rehost it
• replatform it
• refactor/rearchitect it

For example:

Old file server

might become:

SharePoint + OneDrive

rather than:

the same Windows Server running as a VM in Azure.

Microsoft’s current modernisation guidance explicitly separates replatforming, refactoring and rearchitecting because each gives different levels of operational improvement.

The best migration sometimes involves removing infrastructure rather than recreating it somewhere else.

4. Design the Cloud Environment Before Moving Workloads

This is where many SME migrations are too casual.

Do not create the first Azure subscription, virtual network and admin account as you go.

Design the destination first.

That may include:

• subscription structure
• resource groups
• identity
• naming
• networking
• logging
• backup
• security
• access control
• tagging
• cost ownership

Microsoft refers to this foundation as the landing zone and treats it as part of being “Ready” before adoption scales.

A badly designed cloud foundation becomes very expensive to tidy later.

5. Define Security and Responsibility

Moving into the cloud does not mean:

“Microsoft/Amazon/Google now handles security.”

Cloud security uses a shared-responsibility model.

The provider manages part of the platform.

The customer still retains responsibility for areas such as:

• identities
• access
• data
• configuration
• application security

depending on whether the service is SaaS, PaaS or IaaS.

The NCSC explicitly warns that customer responsibility varies with the service model and recommends understanding which controls remain yours.

Before migration, define:

Who secures what?

6. Plan Connectivity Properly

Cloud systems still depend on networks.

Consider:

• broadband
• VPN
• site-to-site connectivity
• latency
• DNS
• firewall rules
• identity traffic
• remote users

A workload might function perfectly on a fast LAN and perform badly after being moved hundreds of miles away behind a slow WAN connection.

Cloud migration planning therefore needs to include:

application dependency + network dependency

not just server specifications.

7. Work Out the Real Cost Before You Move

Do not assume cloud automatically saves money.

Cloud can be cheaper.

It can also become much more expensive if resources are:

• oversized
• left running 24/7
• duplicated
• poorly architected
• never reviewed

Calculate:

• compute
• storage
• backup
• network transfer
• licences
• support
• security
• redundancy
• disaster recovery

Then compare that with the full cost of the existing platform.

The important phrase is:

total cost of ownership.

Not:

monthly VM price.

8. Test in a Non-Production Environment

Do not make the first real test:

migration weekend.

Where practical, create a pilot or non-production environment.

Microsoft’s modernisation guidance recommends validating changes in non-production first, testing thoroughly and supporting the workload through a stabilisation period after deployment.

Test:

• application startup
• authentication
• permissions
• integrations
• printing
• remote access
• backups
• performance
• failover

And test with real users.

IT may think:

“The application launches.”

The finance team may discover:

“Month-end reporting no longer works.”

Those are different definitions of success.

9. Plan Cutover and Rollback Together

A migration plan without a rollback plan is incomplete.

Before cutover, know:

• when changes start
• when writes stop
• how final data sync occurs
• who validates the new system
• who communicates with staff
• how long you tolerate failure
• when you trigger rollback

For example:

If validation fails by 18:00, revert to the existing platform.

That is much better than making the rollback decision while everybody is already under pressure.

10. Treat Go-Live as the Start of the Next Phase

Migration is not finished when users can sign in.

After go-live:

• monitor performance
• watch costs
• check security alerts
• verify backups
• confirm permissions
• remove obsolete infrastructure
• update documentation
• train staff

Microsoft’s framework explicitly includes Govern, Secure and Manage as ongoing disciplines after adoption.

A migration that leaves old servers running indefinitely “just in case” may simply create:

cloud costs + on-premises costs

at the same time.

Do Not Lift and Shift Everything

Lift-and-shift can be the right choice when:

• speed matters
• the application cannot easily change
• you need a staged migration

But it should not be the automatic answer.

Recreating:

20-year-old server architecture

inside:

modern cloud infrastructure

may preserve:

• old complexity
• old security problems
• old licensing costs
• old management overhead

Use migration as an opportunity to ask:

Does this workload still need to exist in this form?

SaaS Is Often the Best Migration

Businesses sometimes think cloud migration means:

moving servers to Azure.

Often the better move is:

stop owning the server completely.

Examples:

Exchange Server → Microsoft 365

local file collaboration → SharePoint/OneDrive

old CRM → SaaS CRM

That transfers more operational responsibility to the provider and can reduce the amount of infrastructure your business has to manage.

The NCSC’s shared-responsibility guidance specifically notes that responsibility shifts substantially as organisations move towards managed cloud services.

Do Not Forget Backup

Cloud availability and backup are not the same thing.

Your migration plan should define:

• what gets backed up
• retention
• off-site copies
• ransomware resilience
• restore testing

A resilient cloud platform does not protect you from every:

• deletion
• compromised administrator
• ransomware incident
• retention mistake

Cloud changes your recovery model.

It does not eliminate the need for one.

Identity Should Be Designed Early

For Microsoft-centric businesses, identity is often the foundation of the migration.

Review:

• Microsoft Entra ID
• MFA
• Conditional Access
• administrator accounts
• legacy authentication
• device identity

Do this before moving sensitive applications and data.

Otherwise the business can end up with:

modern cloud workload + weak legacy identity model.

Data Classification Matters Before Migration

Not every file deserves the same treatment.

Before migrating large file stores, ask:

• what is business-critical?
• what is sensitive?
• what should be retained?
• what can be deleted?
• who should have access?

Migrating ten years of duplicated, obsolete files into SharePoint does not transform them into well-governed information.

It simply creates:

better-hosted clutter.

Train Users Before Go-Live

Users need to know what changes.

For example:

old process:
S:\Shared\Finance

new process:
Teams/SharePoint

If nobody explains that change, employees may:

• create local copies
• email documents to themselves
• save files in the wrong place

Microsoft’s current modernisation guidance specifically emphasises preparing stakeholders and users before deployment.

Technical success without user adoption is incomplete.

Do Not Decommission the Old System Too Early

Keep the legacy system available for the agreed rollback period.

But do not keep it forever.

Once:

• data is validated
• users are operating successfully
• backups are proven
• rollback window has passed

decommission:

• old servers
• old cloud resources
• obsolete VPNs
• unused licences
• duplicate backup jobs

Otherwise technical debt follows you into the cloud.

A Better Ten-Step Migration Model

I would reduce the entire process to:

1. Define the business outcome.
2. Inventory workloads and dependencies.
3. Decide what to retire, replace, retain, rehost or modernise.
4. Design the cloud landing zone and operating model.
5. Define security, identity and responsibilities.
6. Model connectivity, performance and cost.
7. Build and test in non-production.
8. Plan cutover and rollback.
9. Migrate in controlled phases and validate.
10. Govern, secure, optimise and retire legacy infrastructure.

That sequence is much closer to how a successful modern cloud migration should actually be run.

How Hamilton Group Can Help

Hamilton Group can help businesses plan cloud adoption around the workloads they genuinely need rather than simply recreating old infrastructure in a new location.

We can assist with:

• Microsoft 365
• Microsoft Azure
• cloud migration
• hybrid infrastructure
• identity and access
• cloud backup
• business continuity
• cloud security
• modern workplace
• cloud cost optimisation

The objective is not:

“Move everything to the cloud.”

It is:

“Use cloud services where they improve resilience, security, flexibility or cost—and keep workloads elsewhere where that makes more sense.”

Visit hgmssp.com or call 0330 043 0069 to discuss cloud migration and IT strategy.