CypherMax-delivered

Move to the right cloud —
with a way back at every step.

Most migration horror stories come from the same root cause: a cut-over with no rollback. We plan the reverse path before we plan the forward one.

Fit

This is for you if

  • You are running production workloads on physical servers, a colocation rack, or a legacy hosting provider, and support for it is getting thinner every year.
  • You are on a cloud you chose years ago, and your users have since moved to markets it serves poorly.
  • You have been quoted a migration by a provider who also happens to sell only one cloud.
  • You need a presence in a specific market — Indonesia, Vietnam, mainland China — and your current platform cannot give you one.
  • Your last migration attempt stalled, and nobody wants to be the person who proposes trying again.

Scope

What is included

Discovery and dependency mapping

We inventory what you actually run — not what the documentation says you run. Servers, databases, scheduled jobs, integrations, certificates, DNS, licences, and the undocumented script on someone's laptop that turns out to be load-bearing.

Target platform selection

A written recommendation with the reasoning shown: where your users are, what latency they experience today, what your compliance and data-residency requirements are, what you are paying now, and what each candidate platform would cost. Because we collaborate with six platforms, this recommendation is not predetermined.

Migration design

Wave planning, cut-over sequencing, data-synchronisation approach, DNS and traffic-shifting strategy, and a documented rollback procedure for each wave.

Execution

The migration itself, run in waves, starting with a non-critical workload wherever one exists. Cut-overs are scheduled in your maintenance windows, not ours.

Validation and handover

Post-migration verification against agreed criteria, updated architecture documentation, runbooks, and a handover session with your team. If you continue with CloudOps, the runbooks carry straight over.

Scenarios

Migration types we handle

FromToTypical reason
On-premise / colocationPublic cloudAgeing hardware, no disaster recovery, lease expiry
Legacy shared or VPS hostingPublic cloudGrowth beyond what the host can carry, no scaling path
One public cloudAnother public cloudCost, regional coverage, latency, or a specific service you need
Public cloudMulti-cloud splitRegulatory separation, or placing workloads where they run best
AnywhereMainland China regionServing users inside mainland China — see below

Mainland China

Deploying inside mainland China

Serving users inside mainland China from a Singapore or US region usually produces latency your customers will notice. Deploying inside mainland China removes that problem, but the entry requirements are different from anywhere else in Asia-Pacific — and this is one of the areas where collaborating with Alibaba Cloud, Tencent Cloud and Huawei Cloud matters in practice, not just on a logo wall.

We will tell you early if your situation does not support a compliant China deployment. That is a cheaper conversation than finding out halfway through.

What this typically involves

  • A China-region deployment on a cloud that operates there under local licence.
  • ICP filing. A publicly accessible website or app served from within mainland China generally requires an ICP filing, which in turn generally requires a qualifying local entity.
  • Cross-border connectivity between your China-region workloads and everything you run elsewhere in Asia-Pacific.
  • A data-handling review covering what data crosses the border and what must stay put.

Process

How it works

PhaseWhat happensWhat you receive
1. ConsultationA short call to establish whether a migration is actually the right move.A straight answer, at no cost.
2. AssessmentInventory, dependency mapping, platform comparison, risk register.A written assessment and platform recommendation — yours to keep, whether or not you proceed.
3. Design and proposalWave plan, cut-over runbooks, rollback procedures, fixed-price proposal.A migration plan you could hand to another provider if you chose to.
4. Pilot waveOne low-risk workload moved end to end, to validate the plan against reality.A tested plan, with the surprises already found.
5. Full migrationRemaining waves executed in agreed windows, with rollback ready at each cut-over.A migrated environment and verification results.
6. HandoverDocumentation, runbooks, and a working session with your team.Architecture diagrams, runbooks, and an optional move into CloudOps.

Outcome

What you walk away with

  • An inventory of what you run, which most organisations discover they did not have.
  • A written platform recommendation with the trade-offs visible.
  • Rollback procedures for every cut-over.
  • Updated architecture documentation and operational runbooks.
  • A team that has been through the change rather than had it done to them.

FAQ

Migration FAQ

It depends almost entirely on dependencies rather than data volume. The assessment gives you a defensible timeline; before the assessment, any number would be a guess.

Usually some, and we will tell you exactly where and for how long before you approve the plan. Many workloads can be moved with minimal interruption using traffic shifting and data replication; some cannot, and pretending otherwise is how migrations fail.

Every wave has a documented rollback that we test during the pilot. Rolling back is a normal outcome, not a failure — it means the plan met reality and reality won that round.

Yes. If we think the choice is wrong for your situation we will say so once, with reasoning, and then do what you decide.

We review licence portability during assessment and flag anything that will change in cost or compliance terms when it moves.