Windows Server Migration: Preserving Legacy Applications

A Windows Server migration can become urgent before applications are ready for an upgrade. A firewall may have reached the end of vendor support; a hosting arrangement needs to change, and the business may still depend on websites running on Classic ASP or ASP.NET.

This problem was being experienced by a customer who recently approached Atlantic.Net. They wanted to migrate a dedicated Windows server and Cisco firewall stack from Rackspace by January 2027, keeping their Windows Server 2019, IIS, and SQL Server 2019 environment unchanged initially. Application upgrades would follow post-migration.

Our starting point was a dedicated-server proposal that could retain the existing software versions, implement a managed firewall, and be protected by Atlantic.Net backup services. We recommended a staged migration for this kind of environment, provided the applications, access rules, and recovery arrangements pass testing before we cut over production traffic.

In this article, we continue our series of real-world scenarios where customers have approached Atlantic.Net for a solution, and we explain how Atlantic.Net provides a viable, customized hosting solution to meet the client’s needs.

What This Windows Server Migration Needs to Preserve

The customer’s immediate priority was to retain Windows Server 2019, SQL Server 2019 Web, IIS, Classic ASP, and ASP.NET applications with older framework dependencies.

For a business with legacy applications that still run daily, migration can seem daunting at first. Preserving the stack is the priority. Our engineers first needed to logically separate the components that could remain from the configuration changes required by new hardware.

Windows Server 2019 remains in extended support until January 2029, and SQL Server 2019 until January 2030. Those dates give this proposal a supported operating system and database foundation. Individual application dependencies still need their own review, and application upgrades should have an agreed schedule.

This differs from moving an unsupported Windows installation unchanged, which we discussed in our earlier legacy Windows migration article. Here, the immediate work centers on rebuilding and testing the existing application environment on the proposed Windows Server 2019 destination.

The customer’s January 2027 target also needs context. Cisco’s published last date of support for the ASA 5508-X was August 31, 2026, which had already passed when this request reached us in September. That manufacturer date is separate from any hosting-provider service arrangement. We would review the firewall timeline promptly instead of assuming support continues until the planned move.

The Atlantic.Net Dedicated Solution

Our proposed dedicated server increases the available CPU cores and memory while retaining Windows Server 2019 and SQL Server 2019 Web. The revised configuration provides 128GB RAM and a 1,000GB backup allocation.

For the storage layer, we recommended RAID 1 mirrors of each drive. The boot array would provide 240GB usable capacity before formatting, and the data array approximately 480GB. A second data drive supplies redundancy; it does not double the space available for databases and website files.

We would size both arrays against current usage and expected growth. Boot-drive expansion may require substantial work or a host replacement. This proposal would provide additional data capacity through separate RAID 1 arrays.

This was one important limitation our engineers needed to highlight. SQL Server 2019 Web limits a single database-engine instance to four sockets or 16 cores and has a 64GB buffer pool limit per instance. This means that a maximum of 64GB SQL cache will sit in the proposed 128GB of system memory. This is a limitation of that particular version of SQL; it does mean there was plenty of overhead for Windows Server, IIS, and other SQL Server memory allocations.

Testing IIS, Classic ASP, and ASP.NET Before Cutover

Windows Server 2019 supports the required IIS components, Classic ASP, and .NET Framework 3.5. For this environment, we needed to inventory the existing IIS sites, application pools, bindings, certificates, scheduled tasks, database connections, and service accounts.

Classic ASP applications usually depend on registered COM components or particular permissions. Older ASP.NET 2.0/3.5 applications may require specific application-pool settings or 32-bit components. Our engineers needed to complete a full range of tests to ensure compatibility.

We also needed to verify administrative access through the proposed VPN and confirm that certificates and site bindings work with the intended hostnames. Tests should prevent the destination from sending duplicate notifications or running production jobs while the original server remains active.

Replacing the Cisco ASA Without Losing Required Protection

The proposed firewall changes the customer’s recovery arrangement and the firewall product. Their existing configuration used an ASA 5508-X pair for high availability. Our proposal recommended a single managed virtual FortiGate instance, with replication supporting manual recovery.

A replicated firewall can be restored after a failure, but it requires operational work. For a customer accustomed to a firewall pair, we discussed the acceptable interruption before treating a single instance as a suitable replacement. A design requiring automatic failover needs a second firewall instance and an agreed high availability configuration, followed by testing. Both options were available to the client.

Sizing the Firewall and VPN Access

Our proposal recommended a virtual firewall with 10Gbps raw throughput, 100,000 new TCP sessions per second, a.5 million concurrent sessions, and 4 GB memory. This was a big step up from the customer’s existing firewall stack.

The customers’ existing VPN allowance had 100 AnyConnect license entitlements; the new proposal quotes five VPNs. It was a good opportunity for the client to review their requirements and cut costs. Obviously, they could purchase more license entitlements after due diligence.

Agreeing How Rules Will Be Managed

Our team would manage firewall rules, with read-only access available to the customer. The customer would need an agreed process for requesting changes and identifying urgent access issues.

The existing ASA rules provide a great starting point for the FortiGate configuration. Address objects, network address translation (NAT), VPN settings, and rule order require review and can be converted over. We would agree on which rules remain necessary, then test both permitted access and traffic that should be blocked.

Designing Backups Around the Recovery the Business Needs

The proposed Veeam service extends retention from two weeks to 30 days and provides a 1,000GB backup allocation. Daily incremental backups are stored in a separate repository within the same facility. Offsite backups are an option.

If the business needs recovery after a facility-wide incident, an offsite copy or a separate disaster-recovery arrangement needs to be scoped. Backup encryption, access isolation, and immutability should also be agreed as part of the service design.

Recovering SQL Server to a Useful Point

A daily server backup leaves a potential gap between its completion and a later failure. For a transactional application, the business may need a smaller recovery point objective: the amount of recent data it can afford to lose.

SQL Server transaction-log backups support recovery between server restore points when the database and backup jobs are configured appropriately. Veeam’s SQL log-backup supports this requirement. We would agree with the log-backup schedule and test a restore to the required point.

Recovery time extends beyond copying data. Windows must start, SQL Server must recover its databases, IIS must serve the applications, and the business must verify the result. The proposal described a one-hour hardware-replacement commitment after the need for replacement is determined, subject to the agreed SLA terms.

How We Would Stage the Windows Server Migration

We planned the migration in stages, with application testing and recovery decisions completed before the final cutover. The indicative two-to-four-week migration window discussed in this proposal would depend on discovery, customer availability, and the agreed work, leaving room for corrections ahead of the January 2027 target.

1. Confirm the inventory and ownership. Record websites, databases, certificates, DNS records, firewall rules, scheduled tasks, external connections, and application dependencies. Agree which items Atlantic.Net will move and which require the customer’s application team or another supplier.
2. Deploy and configure the destination. Build Windows Server 2019, install and configure SQL Server, enable the agreed IIS features, and prepare the firewall and backup jobs. Record the final storage, addressing, access, and licensing arrangements.
3. Run application and recovery tests. Copy representative data, complete the agreed user journeys, check VPN access, and restore a backup. Compare application behavior with the existing environment and resolve failures before scheduling cutover.
4. Agree to the final synchronization and rollback plan. Set the maintenance window, identify who can authorize the move, and define when database writes stop on the source. Decide how files and databases will receive their final updates and how DNS or routing changes will be applied.
5. Cut over and verify production use. Bring the destination into service, check application transactions and background jobs, and monitor the agreed acceptance criteria. Keep the old environment available for the agreed period, with controls to prevent conflicting writes.

Always include a rollback plan, especially once users start writing new data to the destination. Sending traffic back to the old server could discard those transactions unless the plan accounts for them.

Keeping Hosting and Additional Project Work Clear

Ongoing hosting and included assistance.

The proposal covered the dedicated configuration, specified Windows and SQL licensing, quoted managed services, and four hours of migration assistance. Managed services gave

the customer the defined operational help; the agreed scope to identify responsibilities for patching, backups, firewall changes, and incident handling.

Additional project work.

Four assistance hours do not establish that every website, database, certificate, DNS change, and firewall conversion is included. We would agree on the work after reviewing the inventory. Application remediation and later upgrades need their own scope and owner. If an unsupported operating system requires an upgrade before hosting, we would scope that separately under a Professional Services agreement.

Planning Your Move with Atlantic.Net

Atlantic.Net can help turn an existing Windows hosting specification into a migration scope that your infrastructure and application teams can work through together. We would review the current server, confirm which software versions can remain, and establish the firewall, backup, and support arrangements around them.

For a business in this position, the useful next step is to gather the current configuration, application dependencies, firewall rules, backup requirements, and preferred migration window. Share those with the Atlantic.Net solutions team. We can then discuss a proposed destination, the work required to test and migrate it, and a separate timetable for application upgrades.