Discover: mapping a system across a wall of diagramsDiagnose: reading dashboards to locate the problemDesign: wireframes and interface work for the solutionDeliver: shipping the finished productEvolve: continuous improvement after launchA network operations view during a cloud migration
Measure · Move · Tune

Cloud migration

A move to the cloud with the bill agreed before the migration, not discovered after it. Most migrations deliver the move and miss the point: the same architecture on rented hardware costs more than it did on owned hardware, and nobody budgeted for that.

  • Bill
    Modelled before move
  • Back
    Out at every stage
  • Live
    Throughout the move
  • Yours
    Account and the keys

Sectors that trust us

What is a cloud move?

A cloud migration moves a system onto rented infrastructure and changes enough of its shape that renting costs less than owning. The move itself is mechanical; which services get rearchitected is what decides whether it was worth doing.

Lift and shift, or rebuild for the cloud: which comes first?
Lift and shift gets you off the hardware quickly and usually raises the bill, because the old shape is now rented by the hour. It is the right first step when a data-centre contract ends, and the wrong whole project. We model both bills first.

Key takeaways

  • Bill modelled first: two bills from measured usage, agreed before anything moves.

  • Rehearsed rollback: a tested way back at every stage, run before it is needed.

  • Live throughout: the system stays available for the whole move, no outage window.

  • Your account: account, keys and billing in your name from the first day.

Why bills surprise

Where cloud bills grow.

How bills grow

  • The old architecture is rented, not changed.

  • Egress and inter-zone traffic are never modelled.

  • Test environments run at production size, always on.

  • Nobody owns the bill, so nobody reads it.

How we plan

  • Two bills are modelled before you pick a path.

  • Data movement is measured, not estimated.

  • Non-production scales down, and off overnight.

  • One named owner gets the bill every month.

What we move

From cost model to tuned bill, one rehearsed stage at a time.

  • Cost model and landing zone

    Two bills from measured usage, then accounts, networks and permissions set up before anything moves.

  • Data and database migration

    Replicated, verified and cut over with the old copy still warm, rehearsed on a restored copy first.

  • Service by service

    Moved in an order that keeps the system usable, with a rollback kept until the next stage lands.

  • Observe, then tune the bill

    Logs, metrics and alerts live before traffic arrives; sizing corrected against a month of real usage.

Three ways to move

Move, modernise or rebuild: decided per service, bill beside each.

Today

Hardware you own

Migrate

After

Managed cloud

  • Move as is

    Rehost

    The same system on rented machines, its shape unchanged. The fastest route off the hardware, and the bill usually rises until the next stage tunes it.

    Weeks, not months
  • TypicalMove and fix

    Replatform

    Managed database, containers and scaling where they pay: most of the benefit for a fraction of a rewrite, taken one service at a time.

    Where most estates land
  • Rebuild

    Refactor

    Cloud-native for the few services whose scale or release pace demands it, started only once the bill shows the rewrite pays back.

    Largest saving, longest road

Why SiaSol

Neutral on clouds, strict on the bill.

No reseller margin on any cloud, so the advice follows your workload and your data rules.

  • Neutral choice

    AWS, Azure or Google Cloud, decided per workload.

  • Bill designed in

    Cost is a design input from day one, not an audit afterwards.

  • Data residency

    Residency and backups confirmed in writing, up front.

  • Way back tested

    A tested way back at every stage, run before it is needed.

Platforms we work across

  • AWS
  • Microsoft Azure
  • Google Cloud
  • Oracle Cloud
  • Kubernetes
  • Terraform
  • Docker
  • PostgreSQL
  • Redis
  • Cloudflare
  • GitHub Actions
  • Grafana

How it works · our method

The SiaSol five-phase method, applied to this service.

  1. 01

    Discover

    Most technology projects fail long before the first line of code — they fail at the question.

  2. 02

    Diagnose

    Every slow process has an owner and a cost.

  3. 03

    Design

    Architecture is a set of decisions you live with.

  4. 04

    Deliver

    Software not in production is just cost.

  5. 05

    Evolve

    The handover is the point, not the end.

Where we work

Close where it counts, bilingual everywhere

  • Egypt: Cairo (HQ) and nationwide delivery

  • Saudi Arabia: Riyadh, with teams on client time zones

  • Gulf and beyond: Arabic and English, one delivery standard

Cost & engagement

Cloud migration: cost and stages

Cost follows the number of services and how much data must move; the second dominates more often than expected.

Two bills before anything moves

The cost model is quoted on its own and prices every later stage, so you can stop after it with the two bills in hand.

  • Fixed · two to three weeks

    Cost model

    Two modelled bills from measured usage, a recommendation and a plan with a number per stage.

  • Per stage · quoted from the model

    One stage

    Moved, verified and left in place with its rehearsed rollback, the system available throughout.

  • Monthly · optional

    Cost tuning

    Sizing, reservations and storage tiers reviewed against the real bill every month.

FAQ

What to ask about Cloud migration.

01Will our bill go up or down?

Up, if nothing in the architecture changes, which is the honest answer for a lift and shift. It goes down where specific things change: non-production scaled to zero overnight, storage tiering, and the chattiest traffic between services removed.

02How much downtime should we expect?

None that your users would notice, because each stage runs both sides until the new one has been verified. The database cut-over is the only moment with real risk, and it is rehearsed on a restored copy before it is done on the live one.

03What if we want to move back?

Each stage keeps its rollback until the stage after it is complete, and the rollback is run on purpose before the stage counts as done. We have used one once, on a database cut-over where replication lag proved worse than the test suggested.

04Do we need Kubernetes for this?

Usually not, and we will say so. It earns its operational cost at a scale most estates never reach, and below that a managed container service does the same job with far less to learn. We recommend it when the workload shape actually calls for it.

05Where will our data physically live?

In the region you choose, decided early because it constrains which services are available. Where local data rules apply we confirm residency and the backup region in writing before the landing zone is built, not after the first audit asks.

06Who runs it after the migration?

Your team, and the work is organised so they are the ones doing it well before the last stage. Runbooks, the alert rota and the deployment job all sit in your accounts, and we take the pages alongside your team first, not instead of them.

07Can you move only part of the estate?

Yes, and it is often the right answer for a year or two. A hybrid arrangement costs more in network terms, so the model includes that line explicitly rather than treating the half-move as free. Some systems are cheaper to leave where they are.

08How long does a migration take?

The cost model is two to three weeks and the stages are three to six weeks each, so a typical estate is four to eight months end to end. The schedule depends on how many stages can run in parallel without two risky cut-overs in the same week.

Related services

Often paired with this

Learn more

From the journal

Ready to see the bill before you move?

Tell us what runs where today and what it costs. We come back with two modelled bills, a stage plan and a number for the first stage.

Book a model