On-Prem to Cloud Migration

An on-premise inventory system moved to Azure in pieces. What moved, what stayed on the office server, and how the restore was proved.

On-Prem to Cloud Migration

This page describes a representative move from an office server to Azure. The client is not named. We do not claim a cost cut or an end to downtime. The work was an inventory system that had outgrown the machine in the office, moved in pieces, with a restore test before anyone called the move finished.

The situation

The application was old, and it worked. Stock, goods inward, and a few reports ran on a server under a desk. Backups were a copy someone remembered to take. When the power failed, the office waited. When the disk grew full, someone deleted a log and hoped. The business wanted "the cloud" because a vendor had said the server was a risk. The risk was real. The phrase was not a plan.

A plan has to say what moves, what stays, and how you get yesterday's data back if today's release is wrong. Lifting the whole machine into a virtual server and calling it a migration would have kept every old failure and added a bill.

What we took on

This sat under legacy modernization and cloud. We inventoried the jobs the server actually did: the inventory database, the share where dispatch saved PDFs, the nightly backup, and a small integration that sent orders to the accounts package. The accounts package stayed where finance already ran it. We did not move a system we had not been asked to own.

The database went to Azure with a maintenance window the warehouse agreed. Application screens that staff use all day were pointed at the new database only after a parallel run: a day of receipts entered in the new place and checked against the old. The file share for dispatch PDFs moved with a mapped path the PCs already knew, so we did not retrain the floor on a new ritual. The people on goods inward were told what would look the same and what would pause. A migration that surprises the floor is how the old server gets switched back in a panic.

Restore was a scheduled test, not a sentence in a diagram. We restored a backup to a separate database and read a stock figure we had written down before the backup. Until that number matched, the office server stayed available. A migration you cannot reverse is a gamble, whatever the slide says.

What shipped

The inventory database runs in Azure. Staff use the same screens. The office server no longer holds the only copy. Backups run without someone staying late. The accounts integration still runs on the schedule finance expects. A short runbook says who to call, where the backups are, and how to point the app back if a release fails.

What we refused

We did not rewrite the inventory application in the same project. A new system and a data centre change at the same time gives you two places to look when a number is wrong. We did not publish a smaller bill. Azure costs what you leave running. We sized for the workload we measured, and we left a note on what to shut off if the bill surprises them. We did not claim the office will never have an outage again. The network between the warehouse and the internet is still a single path until they decide to pay for another.

What a similar project needs from you

A list of what the server does on a Tuesday, not what the original manual said. Someone who can confirm a stock figure. A window when goods inward can pause. If you are unsure whether to move the server or replace the software, read legacy and cloud modernization first. We will say which one you are actually buying.

Project information

  • Client: Not named
  • Industry: Distribution
  • Services: Legacy Modernization & Cloud
  • Technologies: Azure, cloud migration
  • Start a similar project