Cloud migration
Moving servers and workloads between on-premises, Azure, AWS and Google Cloud. Copying the server itself is routine. Most of the work is finding everything that depends on it, and making sure that moves too.
- The accounts package and its SQL database
- Not on the inventory: A licence service locked to the server’s hardware ID
- Not on the inventory: The copier’s scan-to-folder share
- Not on the inventory: A nightly bank export, run as a scheduled task
- Mapped drives on every PC
- The backup job and monitoring agent
- Not on the inventory: Mail relay for the alarm panel and label printer
- Not on the inventory: A spreadsheet with the server’s IP address typed into it
Between any of them, in either direction
Most moves are from a server room into a cloud. Plenty aren’t: a client consolidating two clouds into one, or bringing workloads back on-premises because the monthly bill outgrew the reason they left. The method is the same whichever way the move goes; the problems are different.
- On-premises
- Azure
- AWS
- Google Cloud
Into a cloud
Cloud servers are billed for the size you choose, for as long as they run. Sizing from the old server’s spec sheet, rather than what it uses, is how a sensible move becomes an expensive one.
Between clouds
Each provider has its own disk formats, guest agents and network model. A machine lifted from one won’t boot cleanly on another until its drivers and agents are swapped, and its addressing and firewall rules are rebuilt for the new platform.
Out of a cloud
Data leaving a cloud is usually charged by volume, so large datasets need a transfer plan with the cost known before it’s incurred. The on-premises side needs host capacity, storage and backup ready before anything lands.
Each workload gets its own call
Moving everything the same way usually costs more later. For each workload there are three options, and the choice and the reason behind it go into the documentation.
The same server, in a new home. Users see no difference, and nothing about the application changes.
Trade-off: it takes its old operating system, its clutter and its quirks with it.
A fresh server in the destination, the application reinstalled and the data brought across.
Trade-off: more work up front, and it needs the application vendor involved.
The provider runs the platform; the client keeps the data and the settings. One less server to patch.
Trade-off: only works when the application vendor supports it, and it changes how the thing is looked after.
How the call usually falls
| Workload | Usual call | Why |
|---|---|---|
| Domain controller | Rebuild | Copying or restoring a domain controller image risks rolling the directory back and breaking replication. A new one is built in the destination, left to replicate, and the old one is demoted cleanly. |
| Line-of-business application | Move as is, or rebuild if the vendor will | The vendor’s support terms decide this, so their contacts are needed early. |
| SQL Server database | Managed database, if the application supports it | If it doesn’t, it moves with its application server and is sized for its real workload, with its licensing checked for the new platform. |
| File server | Move as is, or a managed file service | A straight move keeps every path and permission. Moving files into Microsoft 365 instead is a file migration, a different project. |
| Remote desktop host | Rebuild | Session hosts are best built fresh on a current operating system, with the applications reinstalled and user profiles brought across. |
What catches migrations out
Very few migrations fail because the copy didn’t work. They fail after cutover, on something nobody wrote down.
-
Distance
An application that was quick across the office network can crawl once its server is in a data centre. Desktop programs that talk to their database constantly feel it first. That gets tested with the client’s own users before cutover.
-
Licences tied to hardware
Some licences are locked to a MAC address, a USB dongle or a host ID. Move the server and the software stops. The vendor has to reissue, and that’s arranged before the window.
-
Addresses typed in by hand
IP addresses hard-coded into applications, scripts, printers and spreadsheets. DNS records are given short lifetimes well ahead of the move, and the hard-coded ones are hunted down.
-
Overlapping networks
If the destination network uses the same address range as an office or another site, the two can’t be joined cleanly later. It’s chosen once at the start, and it’s painful to change afterwards.
-
Sizing from the spec sheet
On-premises servers are bought with years of headroom. In a cloud, the client pays for that headroom for as long as the server runs. Sizing comes from measured use, with room to grow when it’s needed.
-
The tools pointed at the old server
Backup, monitoring, antivirus and patching are pointed at the old machine. Left alone, the new server runs unwatched while the old one keeps reporting healthy. You get a clear list of what changed so your tools can follow.
Cutover, with a way back
The source server is left intact until the client says the new one works. If something fails in the window, switching back is a decision, not a rebuild.
Rehearse
A test copy runs in the destination, and the client’s own people work through their real tasks on it.
Prepare
DNS lifetimes shortened, licences reissued, application vendors briefed, and a window agreed with the client.
Way back open. Restart the source and point DNS back.
Freeze and final sync
Users off, services stopped on the source, and the last changes copied across.
Switch
DNS, firewall rules, mapped drives and connections pointed at the new home.
Client checks
The people who use it confirm it works: open a job, print an invoice, run the bank export.
Sign-off
Only now is the source switched off for good.
Decommission
Switched off and removed from the domain, DNS and licensing. The record lists every step, and any of your tools still pointed at it.
What the client ends up with
-
Migrated workloads
Running in their new home, sized from real use and tested by the people who rely on them, with a list of what changed so your backup, monitoring and patching can follow.
-
As-built documentation
Where each workload now lives, how it’s sized, its network and firewall rules, who holds admin access, and the call made for each workload and why. Written for the engineers who’ll look after it.
-
A decommission record
What was switched off, when, and everything it was removed from. No forgotten server still running, still billing, or still sitting in the client’s inventory.
Under your brand, at a fixed price
Delivered remotely as a white-label project, under your brand or as your named partner. We quote you a fixed price for the agreed scope. The client stays yours, and so does the ongoing service.