Skip to main content
فارسی Book an audit
Audit window
48 hours
Rollback
Every phase
Lock-in
None

The KaraHub method — 2026 edition

Home How we work

How we work

A migration you do not get stuck halfway through

The real fear when changing infrastructure is not that the work will be done badly; it is that it will stall halfway and the office will lose a day. So the route is written down in advance: what happens at each stage, how long it takes, and how we go back if it does not work.

Book an audit Estimate your infrastructure cost

  • Audit window

    48 hours

    From the first meeting to the audit document

  • Response time

    Published

    Every plan carries its own, on the pricing page

  • Rollback

    Every phase

    No stage starts without a way back from it

  • Ownership

    Yours

    Data and configuration handed over at the end

The delivery matrix

Precise engineering along one continuous route

Pick a phase to see what happens inside it, how long it takes, what you are handed at the end, and how we go back if it does not work.

What this phase covers

Delivered in: One to two weeks

Phase 01

Audit

We look at what you have today and write it down: servers, services, licences, backups, and the places where one person is the only one who knows. The output is a document, and it is yours whether or not you continue with us.

  • An inventory Servers, services, licences, and what each one actually runs on
  • What is reachable from outside What the internet can see, and who has access to it
  • Backups, and restore tests The last time a backup was actually restored, not merely taken
  • Dependency on people The places where one person is the only one who knows
What this phase produces The audit document: assets, gaps and risks, in priority order

If it does not go well Nothing has changed; you simply have one more document.

What this phase covers

Delivered in: One week

Phase 02

Plan

The proposed architecture, with figures: what goes where, what it costs, what gets better and what gets worse. The options we rejected are written down too, with the reason.

  • The proposed architecture What goes where and why, with the rejected options and their reasons
  • Costed The cost of the work and the monthly cost afterwards, separately
  • Dated Every stage with a date, and what must be ready before it starts
  • Known risks What could go wrong, and the plan for each one
What this phase produces A route with the proposed architecture, costed and dated

If it does not go well You do not accept the plan and the work ends here.

What this phase covers

Delivered in: Two weeks

Phase 03

Pilot

A small group, usually five to ten people, does real work on the new system while the old one stays untouched. Whatever does not show itself in a pilot will show itself later, during a working day.

  • A small group, real work Five to ten people on the new system, the old one untouched
  • Performance, measured Response time and stability, measured rather than felt
  • What the users said What was slow, what went missing, what needed explaining
  • The fix list What has to be right before everyone moves
What this phase produces A pilot report: what worked, what did not, and what must be fixed before the cutover

If it does not go well The pilot group goes back to the old system. The rest of the company never noticed.

What this phase covers

Delivered in: One weekend

Phase 04

Cutover

The move happens in an agreed window — usually a weekend — with the old system still running and ready to take over. Nothing is switched off until everything has worked for a full week.

  • An agreed window Usually a weekend, with a stated start and end
  • The old system stays up Nothing is switched off until a full week has passed
  • Post-move checks A checklist that is ticked before anyone calls it done
  • Close support The first working day covered by whoever did the work
What this phase produces The new system running, with the old one still up as the way back

If it does not go well Back to the old system, inside the same window. That is why it was left running.

What this phase covers

Delivered in: Monthly, for as long as you want it

Phase 05

Operate

From here the relationship is monthly: monitoring, backups with restore tests, security updates and a monthly report with figures. This is where the plans begin.

  • Monitoring Availability and response time, recorded and reviewable
  • Backups, with tests Daily backup and a monthly restore test
  • Security updates Servers and workstations, on a schedule
  • A monthly report With figures, not adjectives
What this phase produces A monthly report with measured figures and the work done

If it does not go well One month of notice ends it, with your data and configuration handed back.

Migration without downtime

How does anything actually move?

The route each service takes, and the point it can be turned back from.

MIGRATION TOPOLOGY ENCRYPTED TUNNEL // STAGED CUTOVER
The current platform Whatever is working today Left alone until the end A staged cutover One service at a time, in an agreed window ROLLBACK READY Every stage can be reversed The new infrastructure Inside the country, monitored Backed up, and the restore tested
  1. 1 The current platform Whatever is working today
  2. 2 A staged cutover One service at a time, in an agreed window
  3. 3 The new infrastructure Inside the country, monitored
  • The current platform stays up to the last moment; the switch happens once the new one has been tested.
  • Every stage has its own rollback point, written down before it starts.
  • Access is temporary and is closed at the end of the work; what was granted is listed in the handover.

The difference in practice

How this differs from an ordinary consulting project

On KaraHub The usual approach
Starting out A written audit of what you have today, before any proposal A solution proposed in the first meeting, before seeing the infrastructure
Downtime risk A pilot with a small group, then a cutover with the old system still running One move over a weekend, with no way back
Ownership Your data and configuration are yours, handed over at the end Dependency on tooling and access only the contractor holds
Reporting Measured figures, monthly, that you can check A qualitative write-up at the end of the project

Time and team estimate

How long does this take for an organisation like yours?

Pick the kind of work and the size of the organisation.

1. What kind of work
2. What size

From start to handover

2–3 working weeks

The team we assign

  • One network and secure-access architect
  • One deployment engineer
Ask for it in writing

From start to handover

3–5 working weeks

The team we assign

  • One network and secure-access architect
  • One deployment engineer
  • One user-training lead
Ask for it in writing

From start to handover

5–8 working weeks

The team we assign

  • One principal architect
  • Two deployment engineers
  • One user-training lead
Ask for it in writing

From start to handover

8–12 working weeks

The team we assign

  • One principal architect
  • Two deployment engineers
  • One user-training lead
  • One monitoring lead
Ask for it in writing

From start to handover

3–4 working weeks

The team we assign

  • One infrastructure architect
  • One migration engineer
Ask for it in writing

From start to handover

4–7 working weeks

The team we assign

  • One infrastructure architect
  • One migration engineer
  • One cost-monitoring lead
Ask for it in writing

From start to handover

7–11 working weeks

The team we assign

  • One principal architect
  • Two migration engineers
  • One cost-monitoring lead
Ask for it in writing

From start to handover

11–16 working weeks

The team we assign

  • One principal architect
  • Three migration engineers
  • One cost-monitoring lead
  • One monitoring lead
Ask for it in writing

From start to handover

2–4 working weeks

The team we assign

  • One process analyst
  • One automation engineer
Ask for it in writing

From start to handover

4–6 working weeks

The team we assign

  • One process analyst
  • One automation engineer
  • One data and reporting lead
Ask for it in writing

From start to handover

6–10 working weeks

The team we assign

  • One principal analyst
  • Two automation engineers
  • One data and reporting lead
Ask for it in writing

From start to handover

10–15 working weeks

The team we assign

  • One principal analyst
  • Three automation engineers
  • One data and reporting lead
  • One monitoring lead
Ask for it in writing

These estimates are placeholders and are not approved yet; a firm schedule follows the audit.

Want to know how this would go for you?

The first stage is a meeting, not a contract.

Request a Consultation