Legacy application hosting inside the vendor's support matrix

Reading the supported platform list

Take a hypothetical heating and cooling contractor, Calder Ridge Mechanical, where 60 staff use the job costing and payroll application: 40 at the main office and 20 across two branches. It runs on Windows Server 2016 and SQL Server 2016 on one server in a closet at the main office. Main office desks run the client program over the LAN, and the branches connect by Remote Desktop with 2016 RDS CALs.

Vendors call it system requirements, a compatibility guide, a support matrix, or supported platforms. Check the revision date before the rows. A list last revised years ago that stops at SQL Server 2016 records what the vendor tested back then, and it gives the support desk grounds to decline a ticket on anything newer. The verbs carry weight too. On most lists, "supported" means the desk takes the ticket, "tested" means the vendor's QA ran it at some point, and "compatible" can mean little more than a clean install.

For ERP and accounting products, the client rows deserve the same attention as the server rows, because the heavy client runs either at each desk or in a remote session someone has to license.

Calder Ridge's list tops out at Windows Server 2016 and SQL Server 2016 and has no virtualization row. What settles the question is one line from the vendor's support desk, in writing, naming a target platform. For Calder Ridge it would read: Windows Server 2022, SQL Server 2022 with the database at compatibility level 130, running as a virtual machine on a named hypervisor, reached through Remote Desktop Services. When a ticket opens a year from now, that email decides whose problem it is. Silence, or an answer of "not tested", pushes the decision toward paid security updates or the current server.

Windows Server 2022 leaves mainstream support in October 2026, which ends non-security fixes. Its security updates continue until October 2031, so a vendor that certifies 2022 ahead of 2025 still gives the server five years of patches.

Compatibility level 130 after a restore

A newer SQL Server engine can run an old database at its old compatibility level, which gives the vendor a narrower thing to approve. Databases created on SQL Server 2016 default to level 130, and a database carried forward from an older version may still sit at 110 or 120. SQL Server 2022 accepts 100 through 160, and a restored database keeps its existing level. Upgrading the engine while holding the earlier level is a supported approach when the application needs nothing newer.

Check yours with SELECT name, compatibility_level FROM sys.databases; and ask the vendor directly: will you support SQL Server 2022 with our database held at 130?

The level governs Transact-SQL behavior and the query optimizer. Removed features stay removed: the FASTFIRSTROW hint, discontinued in SQL Server 2012, doesn't come back at level 100, the SQL Server 2008 level where it last worked, so the restored copy still needs the business tests described below.

SQL Server upgrades a database's internal version when a 2016 backup restores onto 2022, and a backup taken on 2022 won't restore onto 2016 at any compatibility level. Once staff post work on the new server, rollback means the last backup from the old one plus whatever gets keyed in again by hand, and that cost belongs in the cutover plan.

January 12, 2027 and the rest of Microsoft's calendar

Starting with SQL Server 2016, moving to an Azure VM no longer brings free ESUs, which SQL Server 2014 did get. Outside Azure, SQL Server ESUs go through Azure Arc, covered by Software Assurance or by Arc's pay as you go billing, with a volume licensing route for servers that can't connect. Windows Server ESUs outside Azure need active Software Assurance, active subscription licenses, or licenses bought as license included from a SPLA partner. An OEM copy of Windows Server that shipped with the hardware, with no Software Assurance, meets none of those, and a closet server bought with its operating system preinstalled often runs exactly that.

ESUs keep security patches arriving and change nothing else. Microsoft's ESU FAQ says the program does not extend the product's lifecycle, includes no technical support, and serves as a temporary bridge. A vendor whose terms require a supported operating system may treat a server on ESUs as out of support, so ask that in the same email as the platform question. For a year while the vendor certifies something newer, ESUs can be the right call.

License terms for someone else's servers

Licensing for hosted use is a separate check from whether the application runs, and a migration can create license costs on day one.

Since October 1, 2022, the Flexible Virtualization Benefit has let licenses with active Software Assurance, and subscription licenses, run on an Authorized Outsourcer's shared or dedicated servers. Alibaba, Amazon, Google and Microsoft are Listed Providers and sit outside that benefit. Perpetual licenses without Software Assurance can still go to an Authorized Outsourcer, on servers dedicated to that one customer.

Every user or device that connects to a Remote Desktop session host needs an RDS CAL once a 120 day grace period ends, and the CAL has to match the session host's Windows Server version or be newer. Calder Ridge's 20 branch users hold 2016 CALs, which stop at a 2016 session host. A 2022 session host needs 2022 or newer CALs, and if the 40 main office desks move into sessions too, for the latency reason covered below, the count goes from 20 to 60. That count assumes Calder Ridge buys its own CALs. On a provider's shared servers, perpetual CALs without Software Assurance don't qualify, and the usual route is 60 RDS Subscriber Access Licenses the provider bills monthly under SPLA.

The vendor's own license comes last. Older products tie activation to a hostname, a MAC address, a hardware fingerprint, or a USB key, and any new server changes them, hosted or not. Ask the vendor for the reissue process and whether reactivations count against a limit. Licensing alone can make the current server the cheaper answer until the next renewal.

What a lift and shift does to the monthly close

An application moved as it is keeps every assumption it was built with: steady CPU, local disk with no credit bucket, a LAN that carries broadcast, and one fixed outbound IP address. Burstable instance types, gp2 volumes carried in older templates, and routed networks break those assumptions under month end load, often weeks after a cutover that looked fine. A 12 percent average CPU hides a nine hour posting run, and so does a short lookback window. AWS Compute Optimizer reads 14 days of metrics by default, and AWS's own guidance points workloads with monthly cycles to its 32 day option, so a recommendation built on two quiet weeks never saw the close.

We built our cloud to run software that was never designed for a cloud: on-premise applications in unusual environments. After a migration to Petrichor, our engineers keep adjusting the environment until the application runs well, and the application stays as the vendor shipped it. Each failure below also has a cheap fix on AWS or Azure once someone looks. If the application already runs on EC2, record each instance type, volume type and monthly cost in the workload sizing worksheet before changing anything.

20 percent of two vCPUs once the credits run out

Say a sizing tool sees Calder Ridge's 12 percent average and picks a t3.medium: 2 vCPUs, 24 CPU credits earned an hour, 576 at most in the bank, and a 20 percent baseline per vCPU. One credit buys one vCPU at 100 percent for one minute.

A nine hour posting run with both vCPUs busy spends 120 credits an hour against 24 earned, so a full balance lasts six hours. In Standard mode the instance then drops gradually to baseline, and the last three hours of work stretch to 15. The run finishes after about 21 hours, and the controller sees the close slip a day with no error logged.

Unlimited mode, the T3 default, holds full speed by spending surplus credits, billed at $0.096 per vCPU hour for Windows. This run's worst case is 288 surplus credits, or 4.8 vCPU hours: about 46 cents. The 21 hour close happens only on an instance someone switched to Standard mode to cap the bill, or on a T2, which launches in Standard mode by default and still turns up in older templates. On a Standard mode instance, an alarm on CPUCreditBalance falling toward zero warns before the close stalls. In Unlimited mode, CPUSurplusCreditsCharged shows what each close cost. An instance family without CPU credits removes the question.

gp2 burst balance on a 100 GiB volume

A gp2 volume gets 3 IOPS per GiB with a floor of 100, so 100 GiB means a 300 IOPS baseline, bursting to 3,000 from a balance of 5.4 million I/O credits. Burst duration is the balance divided by burst IOPS minus baseline. A posting run that needs 1,500 IOPS gets 5,400,000 ÷ 1,200 = 4,500 seconds, or 75 minutes, before dropping to 300 IOPS, a fifth of what it asks for. Give it two hours of work at that rate and it spends 225 minutes on the last 45, finishing in five hours instead of two.

gp3 fixes this at a 20 percent lower price per GiB, with 3,000 IOPS and 125 MiB/s at any size and no bucket. The console's create volume screen picks gp3, but volumes made other ways can still come out as gp2, and older launch templates and AMI block device mappings keep asking for it. Find them with aws ec2 describe-volumes --filters Name=volume-type,Values=gp2 --query "Volumes[].[VolumeId,Size,Iops]" --output table, then convert each in place with aws ec2 modify-volume --volume-id <id> --volume-type gp3, with no detach or restart on current instance types.

Check large volumes first. A gp2 volume of 334 GiB or more already gets 250 MiB/s, twice the throughput gp3 includes, and from 1,000 GiB up its baseline passes 3,000 IOPS. Add --iops and --throughput to the modify command for those, or the conversion slows them down. Until the work is done, the CloudWatch BurstBalance metric shows each bucket draining.

Azure's B-series VMs bank CPU credits the way T3 does. Premium SSD disks of P20 and smaller burst from a separate credit bucket that holds up to 30 minutes at the maximum burst rate, and a nine hour close drains it early in the run.

If clients find the license server by broadcast

Azure virtual networks carry neither broadcast nor multicast. AWS VPCs don't carry broadcast either, and route multicast only through a transit gateway built for it, never over Site-to-Site VPN or Direct Connect. A license manager whose clients find it by broadcast on the office LAN starts normally, then every client reports no licenses available. Any routed link between an office and a host drops broadcast as well, so desks left at the office hit this on every hosted setup. Pointing each client at the server by name, usually a setting in a configuration file or an environment variable, fixes it if the vendor documents that option, so add it to the vendor email. Products that connect to a fixed server name never notice.

Printers, scanners, time clocks and payroll files

Edge integrations fail on the first business day after cutover, and every one can be listed beforehand. Payroll checks print on specific stock from a specific tray at each office. Scanners feed supplier bills into the application, a timekeeping application polls time clocks over the office network, and files go to the bank and the payroll provider on a schedule. In a hosted setup the devices stay in the offices and the application reaches them across the link. Petrichor builds that kind of hybrid setup, and hosts older business software of this type with engineering support, including on-premise accounting and timekeeping applications reached from several sites.

Remote Desktop sessions change how each device gets reached. A redirected printer prints through the Easy Print driver by default, and a check layout tuned to the printer's own driver can land off the pre-printed stock, so checks usually go to a network printer the session host reaches directly, with the manufacturer's driver installed on the host. Remote Desktop doesn't carry a desk scanner's TWAIN driver into the session on its own, so most setups switch scanners to scan to a shared folder the application reads. Time clocks need a route from the host to each office's clock subnet, since the timekeeping application polls them by fixed address.

Source IP allowlists at the bank

ACH and positive pay uploads usually leave over SFTP from an IP address the bank allowlisted years ago. After cutover, traffic leaves from a new public IP or a NAT gateway, and the first payroll file gets refused. Payroll providers and tax table services can carry the same restriction. TLS fails from the other side: a new server image with TLS 1.0 and 1.1 turned off can stop an old client that speaks nothing newer, even though the bank changed nothing.

A connection snapshot misses the upload, because the upload runs only on payroll days and at the close, and a ten second SFTP session slips between polls. Windows Firewall logging records every allowed connection once it's on: netsh advfirewall set allprofiles logging allowedconnections enable. Outbound sessions appear as ALLOW lines with the path SEND. The log stops at 4,096 KB by default and discards its oldest entries to make room, so raise it to the 32,767 KB maximum with netsh advfirewall set allprofiles logging maxfilesize 32767, see how many hours a full log covers on an ordinary day, and schedule a copy more often than that. Where Group Policy manages the firewall, set logging in the policy, since it overrides local netsh changes.

A month of logs, including a payroll day and the close, names every partner who needs the new IP. Ask each one how long an allowlist change takes, and file the requests before anyone sets a cutover date. Uploads a clerk makes through the bank's website from a desk never touch the server and don't change. All of this applies to any migration, including one to Petrichor. Migration rehearsal: cutover timings and the rollback deadline covers the rest of the connection inventory.

When a job cost screen makes 2,000 round trips

Some older products keep data in files on a share, read over SMB in small pieces. Others query SQL Server a row at a time. Assume a Calder Ridge job cost screen makes about 2,000 small requests. On the office LAN, at half a millisecond per round trip, it loads in one second. Put 30 milliseconds between the main office and a host and it takes 60. Both latencies are assumptions, and a ping from each office gives the measured numbers.

File share databases carry a second risk across a WAN. A link that drops mid-write can leave the data file needing repair, which a slow screen never does.

The standard answer runs the client next to the data, in a Remote Desktop Services session or a RemoteApp, so only screen updates cross the link. That moves Calder Ridge's 40 main office desks into sessions, which is where the CAL count of 60 comes from, and it brings back the remote access row, since some vendors don't support terminal server installs.

Run last month's invoices on a test copy before cutover

When the accounting server in the closet is the only way a company produces invoices, nobody wants to touch it, because an outage stops billing. The test has to prove invoicing works, run by the people who invoice.

At Petrichor a test copy moves before production does, so the owner can pull back. Our engineers design the target environment, present it, and test it repeatedly with the customer's team before cutover, and a cloud engineer can stand up a version of the application so staff see how it runs before anyone commits.

Before anyone logs in to the copy, turn off its SQL Server Agent jobs and scheduled tasks, and clear its bank, payroll provider and outbound email settings. Otherwise a rerun payroll can send the bank a second ACH file, and a rerun invoice batch can email customers.

Record wall clock time for each task on the old server and on the test copy, because the posting run's duration catches credit and burst problems no functional check will. Restore production at full size. A sample database finishes inside the 75 minute burst window and hides the gp2 limit entirely. After a vendor update or a year of growth, run the table again.

Who calls the software vendor when a posting fails

The usual boundary gives the vendor application behavior and gives the host the operating system, the database server and the network. Anyone who agrees to host vendor software also inherits the vendor's support desk as a party to every ticket, so agree the split before the first failed posting.

Microsoft's support policy for non-Microsoft hypervisors says it may require an issue to be reproduced independently of the virtualization software, even on platforms validated through its Server Virtualization Validation Program. For SQL Server on unvalidated platforms, or any version outside its lifecycle, Microsoft may give limited or no support. Vendors copy that stance, which is why the support statement names the hypervisor.

Agree how the vendor's remote support tool reaches the server, which account it uses, who turns that account on for a ticket, and when it goes off again. For one hosted customer, we patch and maintain a third-party application and coordinate access when its vendor needs in. Our engineers came up through the managed IT business of Trinsic Technologies, INC. That business has run since 2005, and unusual environments are the normal case there.

Some applications should stay where they run today.

Legacy application hosting only pays off when these checks pass. Petrichor's engineers say so when a migration is a bad idea, and why.

• The vendor refuses virtualized or hosted installs in writing. Keep the hardware and press for a supported platform, or use the vendor's own hosted edition if it runs supported versions.
• Hardware in the room carries the license or the data: a USB license key, a serial device, an expansion card. Some of it can be reached over the network, and the vendor decides whether that is supported.
• Perpetual licenses with no Software Assurance can only reach a provider on servers dedicated to you, and the math often favors current hardware until the next renewal.
• An office has one internet link and no backup. A hosted application is down there whenever the link is, so fix the link first or keep the server.
• AWS or Azure already runs it well after the fixes above, or it leans on a managed service the vendor supports there, such as a managed SQL Server offering.
• Surviving the loss of an entire facility is a requirement. We run on our own hardware, in one U.S. data center, and an application that needs more than one facility belongs with a provider that has them.

List the applications, their vendors, and the tasks staff run in them every day, then bring that list to a call with a consultant.