Build
Microsoft 365 and Azure migrations
Servers and VPNs in the office, moved to Entra ID, Intune, SharePoint and Azure Files where they no longer earn their keep, in a planned order, each step with a way back.
The server room goes, one service at a time.
Most firms with 30 to 150 people still run a few servers of their own: sign-in, files, printing, an application or two, and the VPN that reaches them from home. Each one needs patching, backing up and someone who remembers how it was set up. A migration to Microsoft 365 and Azure retires them where the cloud does the job better: sign-in through Entra ID, devices managed by Intune, files in SharePoint or Azure Files, servers that have to stay in Azure. Not in one weekend: service by service, in an order that keeps your people working, with each step tested and reversible before the next one starts.
The route
What moves, in which order.
A migration is six stations on the same route as every Build project. Its switchovers are several, one per service, and each is planned around your projects.
-
Kick-off: the map
Every server, application, share and connection written down with who uses it, and what each one depends on. That map decides the order: what can move early, what has to wait, and what retires without a successor.
-
Access and safeguard
Admin access and emergency accounts in your firm’s own hands, backups of the old environment verified and a restore tested. Nothing moves before it can be put back.
-
Identity and devices first
Entra ID becomes the one place a person’s identity is granted and withdrawn; devices enrol in Intune with a documented baseline and a second factor for everyone. Sign-in moves before the data does, so every later step has a secure door.
-
Files, then applications
Shares move to SharePoint or, where an application needs a drive letter, to Azure Files, organised by matter, client or project. Applications that can’t leave a server move with it into Azure; those with a cloud version are retired.
-
Switchover, service by service
Each service switches out of hours, agreed in advance: final sync, the switch, a check from a user’s seat the same night. Users keep both ways open until the new one is confirmed, then the old one is turned off.
-
Hypercare, then daily operations
Thirty days close to the new setup, the engineers who did the switch answering. Then the handover into Manage, owned by the same TechPilot, or to your own team, with documentation and monitoring.
On record
In the project order and the handover documentation.
- The map: every service, as it was and where it lives now
- The order of the moves, with each switchover’s date
- The restore test before the first move, with its date
- What was retired, and when it was switched off
- The sign-in rules, device baseline and sharing rules, as set
Where your data lives afterwards is written down service by service, so a client’s or an insurer’s question gets a page, not a guess.
What usually goes wrong in a migration.
-
Files before identity
The shares move first, and the second factor and the device rules come later, or never. The new environment opens to any password from anywhere, and the tidying up is harder with the data already in it.
-
The last reason for the domain controller
One service nobody planned for keeps the old server alive for years: the print server, a licence server, an application tied to the domain. The map at the start names it, so it gets a plan of its own.
-
The switch on a Tuesday morning
Everything moved at once, during working hours, with no night to test from a user’s seat and no old way left open. The first deadline after the switch becomes a support marathon.
Also under Build
- Provider exits and takeovers Access secured, systems documented and the switchover planned around your deadlines, even when the handover isn’t friendly.
- Mergers and carve-outs One tenant or two, turned into the structure the deal needs by the legal date, nobody stopping work.
- CAD and BIM environments Workstations, project shares and licence servers built for working across sites, so models stay fast and in sync.
- Office moves and new sites Network, internet, phones and printing ready before the first desk is occupied, with a plan B for the line.
- Rollouts New laptops, software or phones rolled out in waves, a pilot group first, without a lost working day.
Questions we get
Do we have to move everything?
No. A server that earns its keep stays, often in Azure rather than under a desk. The map at the start shows what retires without a successor, what moves and what stays, and you decide with your TechPilot.
What about our plotters and printers once the print server is gone?
Office printers and large-format plotters are deployed straight to the devices that need them, with the manufacturers’ drivers and the settings your teams are used to. No print server to maintain. Our guide explains why the plotter needs that route.
How long is our team on two systems?
As short as the test allows. Each service keeps the old way open until the new one is confirmed from a user’s seat, usually the night of the switch, and then the old one is turned off. The old way closes once the new one is confirmed.
What does it cost?
A project order of its own with scope, milestones and acceptance, billed by time and skill level from the same price list we use for every client. Microsoft’s licences and Azure costs are passed through, and every assumption is written down before the first move.
Start
Still running servers in the office?
In a first call we go through what runs on them today, what would move first, and where the way back would be.
- No first level
- No surprises
- Pilot before you buy