Cloud migration for existing systems
We move established business applications from office servers and ageing hosting contracts to AWS or Azure, with the cut-over rehearsed in advance and the running costs worked out before you commit.
Where the live system is at each point
At every stage of a migration there is a working environment to fall back to.
-
Before
Users work on the office server.
-
Rehearsal
The move is practised with a copy of the data until it is routine.
-
After cut-over
The old server stays untouched until the new one has proved itself.
Why established systems move
Few businesses move a working system to the cloud for its own sake. Something prompts it: the server under the desk is eight years old, the hosting company has announced that the platform is being retired, the operating system has gone out of support, or the business now has people working from home who need reliable access.
In each case the move is an opportunity to fix things that have been tolerated for years: backups that depend on someone changing a tape, a single server with no fallback, a database version long past the end of its support.
Rehearsal is what makes it safe
The risk in a migration is concentrated in the cut-over: the moment users stop using the old environment and start using the new one. We reduce that risk by practising. The new environment is built from scripts so that it can be recreated exactly, production data is copied across, and the whole cut-over is run as a rehearsal, more than once if needed.
By the real cut-over, the steps are written down, the timings are known and the problems have already been found. The old environment is left untouched until the new one has run without incident, so there is always a way back.
Getting the cost right
Cloud bills surprise people because cloud resources are easy to oversize. A server specified “to be safe” costs the same whether or not the capacity is used. We size the new environment from measurements of the existing one, forecast the monthly cost before you commit and review the real bill after the first weeks.
For a system with a busy database, performance tuning before the move often pays for itself, because a well-tuned database needs a smaller server.
After the move
Once the system is in the cloud, ongoing maintenance covers patching, monitoring, backups and cost reviews. The migration also makes later modernisation easier, since new components can be added alongside the old ones without buying hardware.
Talk to us
Describe the system and what you need. You will hear back from someone who can answer technical questions.
Discuss a cloud move 0800 433 7990What a migration covers
- An inventory of what runs where
- Every server, database, scheduled job, file share, certificate and integration the system depends on, including the ones nobody remembers.
- A target design sized to the workload
- Servers and database sized from measured usage, so you do not pay for capacity you will not use.
- A rehearsed cut-over
- The move is practised with a copy of production data, timed, and repeated until it is routine.
- A way back
- The old environment stays intact until the new one has proved itself.
- Backups, monitoring and security from day one
- Automated backups with tested restores, monitoring and alerting, encryption, and access limited to those who need it.
- A cost forecast
- An estimate of the monthly bill before you commit, and a review against the real bill afterwards.
How a migration runs
Discover
We map the system and its dependencies and measure how it is used.
Design and cost
We propose the target environment and forecast its monthly cost.
Build and rehearse
The new environment is built from scripts, the data is copied across and the cut-over is rehearsed.
Cut over
At an agreed quiet time the final data is moved and users are switched to the new environment.
Review and tune
After a few weeks of real use, sizing and costs are reviewed and adjusted.
A good fit when
- The system runs on a server in the office or a cupboard, and the hardware is ageing.
- A hosting provider is retiring your server or raising prices.
- The server's operating system or database version is out of support.
- You need better resilience, backups or remote access than the current set-up gives.
Probably not for you if
- The system controls equipment on site and needs to sit next to it.
- The application depends on software that cannot legally or technically run in the cloud; we check this during discovery.
- You expect the cloud to be cheaper in every case. Sometimes it is not, and we will show you the figures.
“Improved performance, resilience and reduced costs. What a way to start what is now a long-standing relationship.”
Questions we are asked
Will there be downtime?
A short planned window for the final data transfer, usually outside working hours. Because the cut-over is rehearsed, we can tell you beforehand how long it will take.
AWS or Azure?
Either works for most business applications. The choice usually comes down to what you already use, your licensing position and where your other systems live. We will recommend one and explain why.
Does the application have to be rewritten?
Usually not. Most applications can move with configuration changes only. We flag anything that would benefit from change, such as file storage or scheduled jobs, and you decide whether to do it now or later.
What will it cost each month?
That depends on the size of the system and how resilient it needs to be. You get a forecast before committing, based on measured usage.
Can we upgrade the database or operating system at the same time?
Yes, and a migration is a good moment to do it, since the new environment is being built anyway. We test the application against the new versions as part of the rehearsal.
Tell us about your system
Say what it does, what it is built on and what is worrying you. We will reply with what we would look at first and whether we are the right people to help.