The cloud conversation is usually held at the wrong altitude. “Should we move to the cloud?” is not a question with an answer, because the right destination is different for each workload you run. Some things should move today, some should never move, and quite a few are fine where they are until the hardware needs replacing.
Here is the framework we use, and the costs that are routinely left out of the comparison.
Five questions per workload
- How variable is demand? Workloads with peaks — month-end, seasonal, project bursts — benefit most from elastic capacity. A steady workload running at 60% of a server you already own is the weakest cloud case there is.
- Where does the data have to live? Some data is subject to residency requirements or contractual restrictions. Establish this before designing anything, not after.
- How chatty is it? An application that exchanges constant small messages with a database performs badly when the two are separated by internet latency. Move them together or not at all.
- What does it depend on? Applications rarely stand alone. Moving one and leaving its dependencies behind creates the worst of both worlds.
- What happens when the link is down? If a workload must keep running during an internet outage — production control, access control, telephony in some designs — that is a strong argument for keeping it local.
The costs people leave out
Cloud comparisons are usually built on compute price, which is the part vendors publish and the part that is easiest to compare. The items that change the answer are elsewhere:
- Egress. Moving data out is charged. For workloads that serve large files this can exceed the compute cost.
- Connectivity. If everything moves off site, your internet link becomes a single point of failure and probably needs upgrading and duplicating.
- Backup and DR. Cloud platforms are resilient; that is not the same as backed up. You still need your own copies, and they still cost.
- The pilot that never got right-sized. Instances provisioned generously for a migration and never reduced afterwards. This is, in our experience, the single largest source of wasted cloud spend.
- Licensing. Some licences transfer, some do not, and some cost more in a hosted environment. Check per product before committing.
Why hybrid is the common answer
Most established Egyptian businesses we work with end up hybrid, not because it is fashionable but because it follows from the questions above. Email and collaboration move first — the case is overwhelming. Test and development environments follow, because elasticity is genuinely useful there. The ERP or production database frequently stays where it is until a hardware refresh forces the decision, and that is a legitimate answer rather than a failure to modernise.
Right-sizing after the move is not an optimisation task to do eventually. Put a date on it during the project, or you will pay pilot prices indefinitely.
What we would actually do
Assess and classify every workload against those five questions. Produce a road map with a destination and a rough date per workload, sequenced so dependencies move together. Move the easy, high-value things first to build confidence. And review the bill at 30 and 90 days after each wave, because the first invoice is never the steady state.
Strategy first, then the move — and someone to run it afterwards. Cloud Solutions →
