Your infrastructure project, without the drama.
Replacing servers, refreshing a network, or moving to the cloud sounds disruptive. Done properly, it is not: almost all of the work happens alongside your live systems, and the actual switch is a planned window you approve, with a rollback plan sitting ready. This page shows you the whole journey, phase by phase.
Six phases, two decisions.
The mapWhether it is one server or a whole environment, the shape is the same. You make two decisions: which direction to take, and when to cut over. Everything else, including the risk, is ours to manage.
The conversation
30 to 45 minutesNo chargeWhat is driving the change: hardware reaching end of life, an office move, growth, a lease ending, or simply costs that no longer make sense. We listen first, because the driver shapes the answer. Cloud is not always it, and we will say so when it is not.
- What is prompting the change, and any hard dates attached to it
- What must not break: the two or three systems your business stops without
Assessment
Typically 1 to 2 weeks elapsedWe map what you actually have: every server, application, data store and connection, who uses what, and what depends on what. Migrations go wrong when a forgotten dependency surfaces mid-cutover, so this phase exists to make sure nothing is forgotten.
- Servers, storage, applications and how they depend on each other
- Data volumes, and how fast they can realistically move
- Connectivity: whether your internet and network can carry the result
- Backup state, so there is a safety net before anything moves
- Access to the environment (read-only)
- The person who knows each key application
Design & scoping: the plan and the price
Price is fixed hereYou choose the direction; we design the destination in detail and put a fixed price on getting there. The scope also states the new monthly running costs, so you are comparing whole pictures, not just project prices. Old monthly spend versus new monthly spend, side by side.
- The target design, and each phase with its hours
- What moves, in what order, and what is retired
- Cutover windows, and the rollback plan for each
- New monthly running costs next to your current ones
- The payment schedule
- The direction call: cloud, hybrid or refresh
- Blackout dates: payroll runs, end of month, your busy season
Nothing is ordered and nothing moves until you approve the scope. If the numbers say the old servers should run another year, that is a fine outcome, and you keep the assessment either way.
Build & stage
Zero disruptionThe new environment is built next to the old one, not on top of it. Cloud tenancy or new hardware is stood up, security is configured, and your data starts syncing across in the background while everyone keeps working on the current systems. We test migrations on copies before any real cutover.
- New environment built and secured in parallel
- Data seeded and kept in sync in the background
- Test migrations run on copies, timed and verified
- Key applications proven in the new home before anyone relies on them
- A couple of testers to try their day-to-day work in the new environment
- Sign-off that the test results look right
Cutover
You approve the windowUsually out of hoursThe switch itself. It happens in a window you approve, usually an evening or weekend, with your team told exactly what to expect and for how long. A final data sync runs, systems are pointed at the new environment, and everything is tested before Monday morning. If anything material fails the checks, we roll back to the old environment and your team starts the week as if nothing happened.
- Final sync, switch, then a full test checklist
- The old environment held intact as the rollback
- You are told when it is done, not left wondering
- The go decision for the agreed window
- A contact we can reach during the window
Hypercare & handover
First weeks, intensiveThe first days after a cutover get extra attention: we watch closely, fix the small things fast, and check in with your team rather than waiting for tickets. The old environment is only decommissioned after you have signed off that everything works, and the documentation of your new environment is written into your runbook, not left in someone's head.
- Priority response in the first weeks after cutover
- Old systems retired only after your sign-off, then securely wiped
- Documentation updated, monitoring and backup proven on the new environment
Payment, and what changes monthly.
Agreed at scopingA single server, and a whole environment.
Sample plansWhat you can hold us to.
Both ways- A fixed price and named cutover windows before anything moves
- The new environment proven with test migrations before the real one
- A rollback plan at every cutover, and the old system kept until you sign off
- New monthly running costs shown next to your current ones, up front
- Your team told what to expect, in plain language, before every window
- Access, and the person who knows each key application
- Blackout dates and the busy periods we must work around
- A couple of testers before cutover, and a contact during it
- Sign-off at the decision points, so the project keeps moving
Start with the
assessment.
A conversation costs nothing, and the assessment gives you a clear picture of your options whether or not you go ahead. No pressure either way.
