Moving an on-premise database to the cloud
The server in the corner that everything depends on, and that nobody has patched since it was installed.
Moving a production database is routine work done carefully. The difficulty is almost never the copy — it is the applications pointing at it and the cutover window.
Typical timeline: Assessment in 1–2 weeks, cutover in one planned window
Replicate, verify, then switch
These are the signs this is worth doing
If several of these are true, this is usually where the fastest return sits.
Moving a database is well-understood work. The tooling is mature, the paths are documented, and the copy itself is rarely where projects go wrong.
What goes wrong is everything attached to it: the six applications with a connection string somewhere, the scheduled jobs nobody documented, the Access file on someone's desktop that queries it directly, and the report server pointing at a linked server that will not exist afterwards. Migrations fail on inventory, not on transfer.
What the assessment finds
One to two weeks, and it usually surfaces at least one dependency nobody knew about.
- Every application, job, report, and person connecting to the database.
- Database version, edition, and whether the licence travels to cloud.
- Actual size and growth rate, against what people believe it to be.
- Which queries are slow enough to be affected by added network latency.
- A restore test — proving the backups work before anything is moved.
- The realistic cutover window, based on measured copy times rather than estimates.
Managed service or a database on a VM
Both are legitimate. The choice usually comes down to how much control the application actually needs.
Managed (RDS, Azure SQL)
- Patching, backups, and failover handled for you
- Point-in-time restore without building it yourself
- Higher monthly cost, lower operational load
- Some server-level features unavailable
- Right for most business applications
Database on a virtual machine
- Full control, including server-level features
- You remain responsible for patching and backups
- Cheaper monthly, more expensive in attention
- Needed for some legacy or vendor-locked applications
- Right when the application genuinely requires it
Cutover, and the way back
The move itself is done with continuous replication rather than a single copy: the cloud database is brought up to date and kept in sync while the on-premise one stays live. That turns the cutover from a long outage into a short switch — stop writes, let replication catch up, repoint the applications, verify, resume.
The old database is not decommissioned at cutover. It is kept, in a state it can be switched back to, until a full business cycle has run cleanly on the new one. Removing the way back on day one saves a little money and removes every option you might need.
Two things get tested before the real cutover: a full rehearsal in a non-production environment, and a restore from the new backups. A backup nobody has restored is a belief, not a backup.
A database migration is judged entirely on how boring it was. Interesting is the failure mode.
We would rather tell you now than three weeks into a project. This work is usually the wrong call if any of the following describes you.
- Databases with hard data-residency or latency constraints that genuinely cannot be met — some machine-control and lab systems fall here.
- Cases where the application is being replaced within months. Migrate to the new application's database instead of moving the old one twice.
- Anyone expecting cloud to be cheaper by default. It usually is not, line for line; it is more resilient and more flexible. If cost reduction is the only goal, we will show you the arithmetic first.
The systems involved
We integrate rather than replace wherever it makes sense. These are the systems this work most commonly touches.
Database to cloud — questions we get asked
How long is the downtime?
With replication-based cutover, typically under an hour, and scheduled at the start of a quiet cycle. The size of the database affects the sync duration, not the outage.
Will it cost more to run?
Often slightly, line for line — and that comparison usually ignores the hardware refresh, the power, and the hours currently spent maintaining the server. We put both columns in front of you before you decide.
What if it goes wrong?
The on-premise database stays available and in a switchable state until a full business cycle has closed cleanly on the new one. Rollback is a documented step with a named decision-maker, agreed before cutover.
The services this work sits inside
Where this comes up most
The sectors where we most often do this work, and where the payback is usually clearest.
Others worth reading
Modernizing FoxPro, VB6 and Access systems
These systems usually encode two decades of business rules that exist nowhere else. The migration risk is not the code — it is losing the rules.
Read itIntegrationIntegrating Tally with the rest of your systems
Tally's XML and ODBC interfaces are awkward but dependable. Wrapped properly, they let your website, CRM, or operations system exchange data with Tally without anyone re-keying.
Read itThinking about database to cloud?
Start with a short conversation. We will tell you honestly whether this is the right place to begin, or whether something else pays back faster.