Move to the cloud where it pays, and own the rest outright.
A cloud migration done on the numbers, not the brochure. We move what genuinely runs better in Microsoft 365 and Azure. We keep what is cheaper and cleaner on your own servers. Azure Arc links the two, so it all reads as one platform. You stop renting what you could have kept, and what does move earns its monthly cost.
The cloud is brilliant for some things. It is a poor deal for others.
For a few years the advice was simple: put everything in the cloud and stop thinking about hardware. For email, collaboration and anything that scales up and down, that advice was right, and we move plenty of it across. The trouble is the parts where it was never right. Steady workloads that run flat all year, large quiet datasets, the line-of-business application that has worked happily on a server for a decade. Lift those into the cloud and you swap a capital asset you owned for a bill that arrives every month and only ever goes up.
The decision is not whether to use the cloud, but which workloads belong there. We look at what each one actually does, what it costs to run in the cloud against keeping it on kit you own, and how often it really needs to flex. Sometimes the honest answer is the cloud. Sometimes it is a server you bought once, sat in our datacentre or yours, reached through the same identity and tooling as everything else.
Cloud is a rental and on-premises is a purchase. A sound migration decides, per workload, which model costs you less.
Four stages, run end to end, starting with what should move at all.
Work out what should move.
We go through every workload and price it honestly: what it costs in Azure or Microsoft 365 against what it costs on kit you own, how much it really flexes, and what the regulator needs to see. You get a clear split. What belongs in the cloud, what is better kept on-premises, and the figures behind each call so it is your decision, not a default.
Design both halves as one platform.
The cloud side and the on-premises side are designed together, not bolted to each other later. One identity covers both. Azure Arc brings your owned servers under the same management, policy and monitoring as everything in Azure. The aim is that your team sees one platform and one set of controls, whether a workload happens to sit in a Microsoft datacentre or on a server you bought.
Move it across in pieces.
We move a few workloads at a time, prove each one in its new home, and leave the original running until it is. Until a wave is proven, you can fall back to the system you know, a planned step rather than an unplanned recovery. The engineers who designed the move are the ones running it, on a schedule built around your working hours, not against them.
Close it out and stop the rent.
A migration is not done until the old environment is gone. Once a workload is settled, the old one is switched off and the licence or contract behind it actually cancelled, so you stop paying twice. Anything kept on-premises is left documented and supported, not orphaned. You finish with a written record of where everything now lives, what it costs, and who signed off the move.
What earns a place in the cloud. What is better kept on-premises.
A rough guide, not a rule. Every business is different, and we decide each workload on your numbers. But these are the patterns that usually land on each side once the cost and the regulator are both in the room.
Usually worth moving
- Email and calendars. Exchange has earned its place in Microsoft 365, and on-premises Exchange is a maintenance and security burden you no longer need to carry.
- Collaboration that lives where people do: SharePoint, OneDrive and Teams, with the file-share permissions translated properly rather than copied across as they were.
- Identity. Active Directory and Entra ID belong together, with conditional access and the joiner-mover-leaver process sitting above both.
- Workloads that spike and fall away: seasonal demand, project bursts, test and development that is idle most of the month and only worth paying for when it runs.
- Disaster recovery for the things you keep on-premises, so a second copy sits somewhere your building cannot take down with it.
- Anything that needs to be reached cleanly from anywhere, where a cloud front door is simpler than opening up your own network.
- New services you would otherwise buy hardware for, where renting the capacity beats owning a server that sits half-used.
Usually better kept on-premises
- Steady workloads that run flat all year. If it never flexes, you are paying a premium for elasticity you do not use.
- Large datasets that mostly sit still. Cloud storage is fine until you have a lot of it, and getting it back out again has its own bill.
- The line-of-business application that has run well on a server for years, where moving it buys risk and a monthly charge but nothing the business would notice.
- Heavy compute that would cost a fortune metered by the hour, but pays for its own hardware quickly when it runs most days.
- Anything that has to stay close to a specific site or piece of equipment, where the latency or the data-residency rule makes distance a problem.
- Workloads where you would simply rather keep the hardware in-house, brought under Azure Arc so they are managed to the same standard as the cloud regardless.
Three migrations that arrive most often, each decided on the numbers.
The all-in cloud move that turned into a bill nobody can explain.
Everything was moved to Azure some years ago, and the monthly spend has risen steadily since. We go through it line by line, find the steady workloads and quiet storage that are paying cloud rates for no reason, and bring the ones that do not need to be there back onto your own servers. The genuinely cloud-shaped workloads stay put and get right-sized.
Email and files still tied to an ageing on-premises server.
An old on-premises Exchange and a file server that the whole company depends on, both quietly ageing and overdue a refresh. This is the case where the cloud genuinely wins. We move mailboxes to Exchange Online and the shares into SharePoint and OneDrive, in waves, with mail flowing throughout and the permission model rebuilt properly on the way rather than carried over as it stands. The old hardware is retired once the new platform is proven, so a single server failure can no longer take the business offline.
A heavy workload someone wants to lift straight into Azure.
A database or compute job that runs hard most days, with a plan on the table to move it to Azure because that is what you do now. We price it both ways first. Metered by the hour in the cloud it is expensive forever, where a server bought once pays for itself inside the year and keeps running long after. So we keep it on hardware you own, sat in our datacentre or yours, and bring it under Azure Arc so it is governed, patched and monitored exactly like the cloud workloads beside it.
A migration review, with the cost of each option on the table.
A senior engineer goes through your workloads with your team and prices each one both ways.
We map what you run, then put a real cost against each workload in the cloud and on your own servers. You get a clear recommendation for each one, the figures it rests on, and a phased plan to move only what should. Identity, mail flow, dependencies and the order of work are all in it. The plan is yours to take forward with us or elsewhere, and it sets out exactly where the money goes. From there you can have us run the whole move, hand it to a named engineer, take it on as a fixed-fee project, or just call when you need a hand.
- Scope
- Set with you on the first call, against the workloads you actually want weighed up.
- Deliverables
- A recommendation for each workload, with the cloud and on-premises cost beside it. A phased plan for what moves. An identity and mail-flow design. And the commercial shape agreed before any migration work starts.
- Continuity
- Where the review turns into delivery, the engineers who wrote the plan are the ones who run the move, so nothing is lost in the handover.
A migration is the right moment for a security review. Factor1's assessment is a fixed price, agreed before you move.
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.
Tell us what you are thinking of moving, and why.
A short call with the senior engineers who would do the work. Tell us what you run, what is pushing the move, and what the cloud is costing you already if anything is. You will get a straight view of what we would put in the cloud, what we would keep on your own servers, and roughly what each route costs.
