Has anyone migrated a critical monolithic application that has been running on-premises for 25 years or more? Our company is a consulting business with about 300 employees, including a 30-person finance department. We are already almost entirely in the cloud, and our IT team has spent the past year moving our systems. The financial suite is the last major application because it is the largest and most unusual.
The current system was assembled from several older applications and vendors. Three finance databases synchronize through bridge tables that translate legacy IDs into newer ones, and there are also unexpected dependencies involving print servers, SMTP relays, scheduled jobs, and file transfers. We expect to clean up and restructure some database elements before moving it.
Our current plan is an Azure IaaS deployment with database servers and application servers hosting the existing platform. What has been your experience moving a business-critical legacy system to the cloud? Were there unexpected technical dependencies, reliability problems, cost surprises, or operational issues we should plan for?
6 Answers
Put the infrastructure in code from the beginning with Terraform or Bicep, and keep the deployment, network rules, identities, backup settings, and operational notes in version control. Portal-only builds are difficult to audit and nearly impossible to recover when the original consultant leaves. Reproducibility matters just as much as the initial migration, especially for a system this old.
Be very clear about whether you are moving to SaaS or IaaS. They have completely different tradeoffs. With IaaS, you may be able to move the application with relatively few code changes, but you still own the operating system, database, backups, security, patching, and disaster recovery. SaaS can reduce that burden, but it may not meet your compliance or customization requirements.
Do not assume that matching your current server sizes in the cloud will be economical. Older on-premises database servers are often oversized and have never been revisited. Right-size the VMs, consider reserved capacity where the workload is predictable, and account for data transfer charges if feeds still move between Azure and your offices. Also price the supporting services: backups, firewalls, VPN gateways, monitoring, and redundant regions.
For a mostly static workload, dedicated or bare-metal hosting may be worth comparing with IaaS. The cloud is most compelling when you actually use elasticity, automation, and managed services rather than simply renting an equivalent server.
The biggest surprises are usually hidden dependencies, not the virtual machines. Monitor the application and database servers for a couple of weeks with tools such as tcpdump or netstat, and inventory scheduled tasks, ODBC connections, file shares, SMTP relays, printers, scripts, and reporting workstations. Old ERP-style systems often depend on things nobody remembers documenting.
Capture performance baselines before the migration, including month-end close times and large report runtimes. Keep the old environment intact but disconnected for a genuine rollback period. That gives you something concrete to compare against when users say the new system feels slower.
Treat the migration as an application-discovery project, not just a server move. Document every integration and ownership boundary, test month-end and reporting workflows with finance users, and rehearse both cutover and rollback. A staged migration or parallel run can expose data-mapping problems before they affect billing. Also make sure the team has a plan for provider-account lockouts and support escalation, since not every outage is a technical failure inside the application.
Cloud is not automatically a disaster-recovery strategy. A single region, subscription, identity system, or provider account can still be a single point of failure. Define how the finance system will operate during a provider outage, including backups that are independent of the primary environment, tested restores, regional recovery, and a documented break-glass process.
At the same time, one on-premises data center is also a major failure domain. A properly designed multi-region Azure setup can be more resilient than one building, but that resilience costs money and has to be tested rather than assumed.
The application is used mainly for customer billing and accounting; it does not handle vendor payments or other operational finance processes. We are still concerned about outages, but we have local caching so consultants can record billable hours if the main system is unavailable.
We already found that user-specific finance IDs are stored on a print server because the company once billed clients for printing. There is also an unnecessary SMTP relay between the application and the print servers. We will definitely use network monitoring to uncover more of these surprises.