Home/Expertise/Cloud modernization
Cloud modernization
For a long-lived business application, "move to the cloud" is rarely one project. It is a sequence of decisions about which part goes first, which parts gain nothing from moving, and what has to change before either is safe.
Sequencing
The order matters more than the destination. Moving the wrong part first produces a migration that is technically complete and operationally worse.
Preparation
Nothing exotic. It is a short list of assumptions that were entirely reasonable on a server in your own building, and stop being reasonable once there is a network in the middle.
Connection strings, paths and endpoints stop being compiled in or hard-coded, so the same build can run in more than one environment.
Temporary files, shared folders and "the export directory" all need somewhere to live that survives an instance being replaced.
On a LAN it effectively never did. Retry, timeout and reconnect behaviour that was never needed suddenly becomes the difference between resilient and unusable.
Logging and error reporting you can read remotely. Nobody is going to walk to the machine and look at the console any more.
Every item on that list is worth doing anyway. They make the system easier to test, deploy and diagnose whether or not it ever moves — which is why this work is safe to start before the platform decision is final.
Position
A system with its database and integrations in the cloud and its desktop client on company machines is not a project someone abandoned halfway. For a lot of enterprise software it is the arrangement that actually makes sense — and treating it as a failure state is how organisations end up moving things that had no reason to move.
Questions
We work to the requirement rather than to a vendor. If you already have a platform and a contract, that is the one we work on.
If you are still choosing, the decision is usually driven by where your data is allowed to live, what your own team can realistically operate, and what the workload actually costs there — not by comparing feature lists.
Sometimes, and not automatically. A steady, predictable workload running on hardware you have already paid for can easily cost more in the cloud, and anyone who promises otherwise without looking at your usage is guessing.
What usually improves first is elasticity, recovery, and the time it takes to provision anything at all. Those are real gains — they are just not the same gain as a smaller invoice.
No, and for most long-lived business applications you should not plan to.
Move the parts that gain something and leave the parts that do not. A partial migration that stops at the right place is a better outcome than a complete one that went past it.
Not by itself. A desktop client is largely indifferent to where the database and services run, provided the network behaviour is handled properly.
The work is in connection resilience, latency assumptions and configuration — not in replacing the client. Chatty data access that was invisible on a LAN is the thing to look at first.
Next step
Tell us what the system looks like today and what is driving the request. The useful first answer is usually which part should move first — and which parts should not move at all.
