Cloud migration
Cloud migration, done in stages rather than all at once
Most small business cloud migrations happen because a server is reaching end of life and nobody wants to buy another one. That is a perfectly good reason. What makes them go badly is doing everything at once, over a weekend, with no way back.
- Staged, with a way back
- Honest about what stays
- On-site for the messy parts
The trigger is nearly always hardware
Businesses rarely move to the cloud because of a strategy. They move because the server in the cupboard is seven years old, out of warranty, and a replacement is several thousand pounds that will need doing again in five years. At that point paying monthly for something somebody else maintains starts to look sensible.
That is a good reason and it is worth being clear that it is the reason, because it sets the scope. The job is to get files, email and the applications that can move off the ageing hardware, not to redesign how the business works.
The other common trigger is people. A business with staff working from home half the week discovers that a file share designed for an office is painful over a domestic connection, and the workarounds it produces are worse than the original problem.
Migrations sit within the wider work covered under business IT support.
How we run a migration
In stages, with each one reversible, rather than as one weekend everybody dreads.
-
Step 1
Inventory what is actually there
Files, mailboxes, applications, the database nobody mentioned, the machine in the corner running something critical. The surprises found at this stage are the ones that would otherwise derail the move.
-
Step 2
Decide what moves and what does not
Some things should stay on site, and saying so is part of the job. A line-of-business application that performs badly over a connection, or hardware that has to be local, is not improved by moving it.
-
Step 3
Move email first
Usually the cleanest win and the one that proves the process. Mail copied across before the switch, the change made at a quiet point, both routes working briefly while it settles.
-
Step 4
Then files, in groups
A department at a time rather than everything at once, with the old share still readable until the new one has proved itself. Permissions rebuilt deliberately rather than copied along with whatever had accumulated.
-
Step 5
Applications last, and only where sensible
The hardest part, and the one where the honest answer is often to leave something where it is or replace it entirely rather than lift it into a place it will run badly.
-
Step 6
Decommission properly
The old server switched off only once nothing has needed it for a period, with a final backup kept and the disks disposed of properly rather than left in a cupboard.
What should not move
A migration that moves everything is usually a migration that is going to hurt. Some things genuinely belong where they are, and a provider who says so is worth more than one who quotes for lifting all of it.
Applications that are sensitive to latency frequently perform worse in the cloud than on a local server, particularly older line-of-business software designed on the assumption of a fast local network. Moving those without testing produces a system everybody complains about and nobody can fix.
Machines tied to hardware stay put by definition: anything running a controller, an imaging unit, a production line or a piece of equipment with a serial connection. Large working files that get opened and saved constantly, in design or engineering work, often stay local with a synchronised copy rather than living remotely.
And occasionally the honest answer is that a system is due for replacement rather than migration, and spending money moving it is spending money twice.
What stays on site still needs looking after, which is covered under servers and backups.
What we handle
- A full inventory before anything moves, including the systems nobody remembers until they break
- A written plan with stages, what each one costs and what the way back is at each point
- Email migration with history intact and both routes working while it settles
- File migration in groups, with permissions rebuilt deliberately rather than inherited
- Backups of the new arrangement, tested, because cloud storage is not a backup and losing that distinction is expensive
- Staff shown how the new arrangement works, on site, rather than sent a document
- Old hardware decommissioned properly, with a final backup kept and disks disposed of securely
- An honest account of the ongoing monthly cost against what you were spending before
Server out of warranty?
That is usually the point at which this becomes urgent rather than interesting. The worst version of this project is the one that starts the week after the hardware fails.
The free review covers what you have, what it would cost to replace against what it would cost to move, and what should stay on site either way.
Get in touch
Talk to us about cloud migration
A few lines is enough. We will tell you straight whether we can help, what it would cost and how quickly we can be there. No hard sell, and no follow-up sequence if you decide against it.
- We reply within one working day
- A straight answer, including when it is no
- Free process review available, before any money changes hands
Would rather just ring? 01623 354250, Mon–Fri, 9am–5:30pm.
Frequently asked questions
If the answer is not here, ask us. You will get a straight one, from someone who does the work.
Mon–Fri, 9am–5:30pm
How long does a cloud migration take?
For a small business, typically a few weeks in stages rather than a single weekend. Email is usually first and quickest, files follow in groups, and applications last. Doing it in stages costs a little more in time and removes almost all of the risk.
Will we lose access to anything during the move?
That is what the staging is for. Mail is copied before the switch with both routes working briefly, and old file shares stay readable until the new arrangement has proved itself. Nobody should have a day where they cannot work.
Is the cloud cheaper than a server?
Not automatically, and anyone who says otherwise is skipping the arithmetic. You trade a large capital purchase every five years for a monthly cost that never stops. It usually works out sensible for small businesses, and it depends on headcount and how much storage you actually use. We will do the sum with real numbers.
Do we still need backups if everything is in the cloud?
Yes, and this is the most expensive misunderstanding in this area. Cloud storage protects you from hardware failure. It does not protect you from a file deleted in error, a malicious deletion or ransomware encrypting what then syncs. Backup is a separate arrangement and it needs testing.
What if some of our software cannot move?
Then it stays, and that is a legitimate outcome rather than a failure. Latency-sensitive applications and anything tied to hardware are usually better where they are. A hybrid arrangement is what most small businesses actually end up with.
What happens to the old server?
It stays powered on until nothing has needed it for a while, then it is decommissioned properly: a final backup retained, and the disks wiped or destroyed rather than left in a cupboard for somebody to find in three years.
