Cloud Migration for Legacy Applications

What makes legacy applications hard to move

Legacy applications were built for a server room, and they carry assumptions that break in the cloud. Connection strings point to hard coded IP addresses, file paths reference a mapped drive, scheduled tasks run on one specific machine, and login depends on Windows authentication inside the office domain. Some apps talk directly to label printers, scanners or plant floor equipment on the local network. Tepia finds these dependencies before choosing a migration path, because each one changes the plan.

Support deadlines usually force the conversation. Windows Server 2012 and 2012 R2 reached the end of extended support in October 2023, and SQL Server 2012 in July 2022, so many companies run critical apps on platforms that no longer receive regular security updates. Those same applications are often the ones nobody wants to touch, which is exactly why they need a careful plan rather than a weekend server copy.

Choosing a migration path for each application

Tepia sorts every application in the portfolio into one of seven paths, using the inventory from Discovery:

Most portfolios end up with a mix. Tepia typically rehosts or replatforms the bulk of applications first, then refactors the few where new features or scale justify deeper work, using our cloud architecture patterns on AWS, Azure or GCP.

Moving the data and cutting over

Data is where migrations go wrong. Tepia sets up continuous replication from the on premises database to the cloud target using tools such as AWS Database Migration Service, Azure Database Migration Service or native SQL Server and PostgreSQL replication, so the cloud copy stays current for weeks before cutover. Validation queries compare row counts and key totals every day.

The cutover itself is rehearsed. Tepia runs at least two practice cutovers in a staging environment, times each step, and writes a checklist with an owner and a rollback trigger for every stage. DNS records get short time to live values ahead of the switch, a change freeze starts a few days before, and the old environment stays available for a defined period in case a rollback is needed. For most applications the final switch fits inside a planned maintenance window.

Running well after the move

A migrated app that is hand configured in a console is just a legacy server in a new building. Tepia defines networks, compute, databases and permissions as infrastructure as code with Terraform, AWS CloudFormation or Azure Bicep, and deploys application changes through a CI/CD pipeline. Every environment can be rebuilt from source, reviewed in a pull request and audited later.

• Backups with scheduled restore tests, not just backup jobs that report success.
• Monitoring and alerts in CloudWatch, Azure Monitor or Google Cloud Monitoring, routed to the people on call.
• Least privilege access roles, encryption at rest and in transit, and logs retained to SOC 2 aligned standards.
• Right sizing reviews after a month of real usage, since on premises sizing rarely matches cloud demand.

Our DevOps and CI/CD team handles pipelines and runbooks, so your staff inherit an environment they can operate.

How Tepia approaches cloud migration

Tepia runs cloud migrations through the same six phases it uses for every engagement, organized into waves and led by a US based project manager.

1. Discovery: an inventory of servers, applications, databases and network dependencies, interviews with application owners, and a review of support deadlines and compliance needs. Deliverables are an Investigation Summary with a migration path for each application, an Interview Summary and User Stories such as a plant supervisor printing labels after the move.
2. Design: a design questionnaire for operational requirements, a target architecture, landing zone and network design, and wireframes for any admin or status screens that change.
3. Development and Testing: infrastructure as code, replication setup and application changes, with an Alpha migration of a low risk app and a Beta wave, backed by functional, performance and failover test plans.
4. Training: runbook walkthroughs for your IT team and short guides for users if login or access changes.
5. Launch: rehearsed cutovers in waves, data migration with validation, transition from the old servers and support reps watching the first business days.
6. Support: issue resolution, patching, right sizing reviews and feature requests on the modernized apps.

Typically Discovery takes 1 to 3 months, build and QA 2 to 6 months depending on how many applications move, and each launch wave about a month. See our process.

Hybrid setups and what should stay put

Not everything should move at once, and some systems should not move at all. Applications that drive local equipment, such as label printers on a packing line or PLCs on a plant floor, often stay close to that equipment while their data syncs to the cloud. Tepia connects the two sides with site to site VPN, AWS Direct Connect or Azure ExpressRoute, and keeps identity in one place through Microsoft Entra ID or Okta.

Migration also changes how systems talk to each other. Once an app runs in the cloud, it can expose APIs to Salesforce, NetSuite or a mobile app far more easily than it could from behind an office firewall. Tepia often pairs a migration with that integration work, which is where much of the business value shows up. Read legacy system modernization and systems integration services, then talk to Tepia about your server list.

Frequently asked questions