Your servers moved across in pieces, the old ones kept running until the new ones are proven.
For teams whose servers are ageing out, whose hypervisors are due a refresh, or whose main application platform is one renewal away from forcing a decision. We build the new servers clean, move your data and applications across one piece at a time, and leave the old kit running until the new is proven. There is no single cutover weekend, and no downtime you need to announce to the business.
Running the old and new servers side by side keeps you live while we prove the new one works.
A move that goes wrong almost always goes wrong on the application or the data, not the operating system. The day-to-day business application that only one version of the software will tolerate, the database that takes a day to copy, the link to another system that nobody wrote down. We build the new servers clean, move each one across when it is ready, and keep the old as the way back. You move from one proven server to the next, with no period where the outcome is uncertain.
We build the new servers clean and move your workloads across in stages, and prove each one before the old server is retired.
-
We learn what each server really does before we touch it.
We map the physical and virtual servers and how they are arranged. We note where the data sits and how big it is. We record the business applications each server runs, the versions they will and will not tolerate, and the background accounts and scheduled jobs that other systems quietly depend on. The applications and the data are where most migrations succeed or fail, so that is where we concentrate. You get a working map that both your team and ours rely on throughout the project.
-
The target is chosen per server, never one rule for all of them.
A server two versions behind that an older application depends on calls for a different approach to one that simply needs a newer operating system. So we decide it server by server: a clean build on current Windows Server for most, a fresh cluster or Azure Local where the workload fits it, an in-place upgrade only where it is genuinely the safer route. Support dates are read from Microsoft against the build numbers your servers actually report when work starts, so the plan reflects your actual environment rather than out-of-date records.
-
Workloads move one at a time, in the order the dependencies allow.
A server that many other systems depend on is moved at a different stage to one that runs a single isolated report. We sequence the move by what depends on what and by how much downtime each one can take, which for most is none. The bulk of the data copies across in the background ahead of time, so the actual switch is short and planned. Each window is agreed with the people who own that application before anyone is asked to approve the change.
-
The old server stays up as the way back until the new one has proven itself.
We agree up front what "working" means for each application, then watch the new server carry the real load before we touch the old one. The old server stays running throughout, so if anything looks wrong we point straight back to it, with nothing lost and no emergency recovery to run. The person you reach is the senior engineer who planned the work, not a call centre. The old server is only retired once its replacement has proven itself, and where it is in scope we confirm the new setup backs up and restores before we call it done.
-
The old equipment is only decommissioned once it is confirmed safe to do so, with evidence recorded.
A decommission checklist signed off server by server: workloads moved and confirmed running elsewhere, last connection logged, machine powered down, asset retired, licences handed back, the datacentre or cloud line taken off the bill. No server is left powered on through uncertainty, and none continues to incur charges because its status was unclear. Anyone who needs to confirm the old setup is gone gets the record for it, and the engagement does not close until that checklist is complete.
The age and support state of each server, and what it means for your renewal decisions.
Age drives most of the plan. A server still in mainstream support, one nearing the end of support, and one Microsoft has already stopped patching each require a different plan and timeline. Lifecycle dates also shift as products age, so we read the current ones from Microsoft against the build numbers your servers actually report, not from memory or an article written last year.
You get each server with its support state, the date the next change lands, whether Extended Security Updates buy you useful time, and how that cost compares with building clean now. Where paying for another year is the sensible call, we say so. Where it is not worth spending more on ageing equipment, we say so, with the reasoning set out for finance. Your IT lead, finance and audit all read the same figures, dated the day they were taken.
Four situations that bring a server migration onto your agenda.
Hosts out of support, and a renewal quote that finance is questioning.
The hardware support contract is up and the figure has made someone in finance ask whether it is worth paying again. The servers and the operating system under them are both due. We work through it server by server, looking at what each one actually carries: refresh the hardware, fold the workload onto a newer cluster, or take it to Azure Local. The decision follows each workload, not a single rule applied across every server.
A half-finished migration that left a mix of systems with no clear owner.
The first wave moved the obvious workloads, then stalled, and what is left spans versions, hypervisors and locations with no clear owner. We assess it plainly: what should be retired, what should be consolidated onto a current platform, and the occasional system that is rightly left where it is. Then we finish what was started, piece by piece, with the old kept as a fallback.
An application server upgrade stalled because nobody knows what it touches.
The person who set it up left two years ago and the platform is a couple of major versions behind, but nobody can plan the upgrade because nobody can say what depends on it. We work out what feeds it, what it feeds, and which service accounts and scheduled jobs quietly hold it up. Once the application and its data are mapped, the move itself is comparatively straightforward.
A datacentre exit with a hard date already on the calendar.
The contract on your hosted datacentre space is ending, a parent company is consolidating, or a building move has set a hard date. There is little value in relocating servers you would replace within a year. So we treat the deadline as the moment to build clean for the ones that were due anyway and move the rest across in pieces. That turns one planned disruption into a refresh, rather than two separate ones.
A server-migration review, and a move plan ready to put in front of whoever signs it off.
- Duration
- We tell you on the first call, usually days rather than weeks. It tracks how many servers you run, how current your records are, and whether anyone has mapped the applications already.
- Deliverables
- A map of your servers and what each one really does, their ages and support state read from Microsoft, a move plan that goes piece by piece with the order set out, and a checklist for retiring the old kit.
- Continuity
- The senior engineers who learn your environment are the ones who carry it into the move. The plan holds enough detail for another firm to run it if you choose.
Our engineers work inside your environment and produce a written move plan, with the sequence set out, at the end.
We map your physical and virtual servers and how they are arranged, the business applications and the data behind them, and what depends on what. Ages and support state are read from Microsoft when the review starts, with a view on whether Extended Security Updates are worth it. You finish with a plan you can put in front of whoever signs off the change: build clean where it fits, move one piece at a time, the old kit left running as a fallback, and a checklist for retiring it once the new is trusted.
Factor1's monitoring follows the workloads through the move, so nothing drops out of view mid-migration.
The migration is one piece. We look after the whole.
Under one agreement, the estate is watched, maintained and documented as a single thing, by the team behind this page.
…and everything between.
Cardiff base, working remotely. Factor1, our cybersecurity arm, on hand where the move touches it.
Tell us which servers are causing you concern.
A short call with whoever would lead a server migration on your side. Tell us the versions and hypervisor mix as you understand them today, any renewal or end-of-support date looming, and the applications you are least sure about. You will come away with a clear view of which workload should move first.
