Server 2016 and SQL Server 2016: the legacy-app checklist.

SQL Server 2016 extended support ended on 14 July 2026. Windows Server 2016 extended support ends on 12 January 2027. Use this list to move the old applications that depend on them without losing data or a working day.

40 checks in 8 stages. Vendor-neutral. Ticks are remembered in this browser only; nothing is sent anywhere.

Organisation: ______________________ Owner: ______________________ Date: ____________

01Know what you have and when it runs out

Start with facts. Most delays come from a server or database nobody knew was still in use.

List every server running Windows Server 2016Include virtual machines, the server under the desk and anything a third party hosts for you. On each: winver, or in PowerShell Get-ComputerInfo | Select-Object OsName, OsVersion (2016 is build 14393).
List every SQL Server 2016 instanceRun SELECT @@VERSION; on each instance (2016 is version 13.x). Include instances installed silently by line-of-business software.
Record the support dates against each oneSQL Server 2016 extended support ended on 14 July 2026. Windows Server 2016 extended support ends on 12 January 2027. Check both on Microsoft's lifecycle pages.
Decide a route for each server and instanceUpgrade in place, move to a new server, move to a hosted service, pay for Extended Security Updates where you are eligible, or retire. Write the decision down with a target date.
Name an owner for every applicationOne person who can say what the application is for, who uses it and who can sign off that it still works after the move.

02Inventory each legacy application

For each application on those servers, including Visual FoxPro, Microsoft Access and other desktop databases.

Name, version and who supports itIs the original developer or vendor still around? Do you have the source code, or only the compiled application?
Runtime and dependenciesFor example the Visual FoxPro 9 runtime files, Access runtime, Crystal Reports, ActiveX controls, COM components and any DLLs registered on the server.
Database drivers and connectionsODBC data sources (DSNs), OLE DB providers and connection strings. Note which are 32-bit only: the Visual FoxPro OLE DB provider is 32-bit.
Where the data livesFolders and shares holding the data files (for FoxPro: .dbf, .cdx, .fpt; for Access: .mdb, .accdb). Record mapped drive letters and UNC paths written into configuration files or code.
Scheduled tasks and servicesOvernight imports, exports, backups, report runs and any Windows service the application installs.
LicencesRuntime redistribution rights, client access licences, and whether the application's licence is tied to the server name or hardware.
Users and how they connectDesktop shortcuts on a file share, Remote Desktop, Citrix, or a local install on each PC. Count named users and the busiest times.

03Map what writes and what reads

The move breaks things at the edges. Find the edges before you start.

Every process that writes to each tableThe application itself, import routines, scheduled jobs, macros, other applications and people editing tables directly.
Every process that reads from itReports, spreadsheets with live connections, BI tools, label printers, web shops and any other system pulling data.
Every place data is typed in by handOrders from email, bookings from portals, delivery notes, stock counts. These are re-keying routines; note how often each runs and who does it.
Files that arrive and leaveCSV drops, EDI files, emailed spreadsheets and FTP folders, with their schedules and who depends on them.
Integrations with outside partiesCarriers, customers, suppliers, banks and accountants. Who needs to be told if a file, address or schedule changes?

04Protect the data before anything moves

Nothing in this section changes the live system. Do all of it first.

Take a full backup and restore it somewhere elseA backup is only proven when it has been restored on a different machine and the application opened against it.
Record row counts and checksumsFor each table: number of records and a file checksum (for example Get-FileHash in PowerShell), so you can prove the copy is complete.
Record permissions and service accountsFolder and share permissions, SQL logins and the accounts that scheduled tasks and services run as.
Work from a read-only copy for discoverySurvey and test against a copy. Do not point new tools at live data files until you have a tested process.
Agree who can change what during the projectA freeze on schema changes and new customisations while the move is planned and tested.

05Test on the target before the move

Build the new server or database as close to production as you can, and test with real routines.

Install the runtimes and 32-bit driversConfirm the application starts, connects and can write on the new operating system.
Check file sharing and lockingShared-file databases such as FoxPro and Access are sensitive to SMB caching and locking. Apply the settings the application's supplier recommends and test with several users at once.
Check paths, printers and regional settingsMapped drives, UNC paths, default printers, date formats and code pages. Old applications often assume all of these.
For SQL Server: compatibility, jobs and loginsDatabase compatibility level, deprecated features, SQL Agent jobs, SSIS packages, linked servers, logins with matching SIDs, collation and TLS 1.2 support in older drivers.
Run the real routines end to endMonth-end, imports, exports and key reports on the test copy. Compare totals and sample records with the old system.
Time the slow jobsOvernight jobs that finish late on new hardware or across a network can collide with the working day.

06Plan the cut-over and the way back

Decide in advance how you will know it worked, and what you will do if it did not.

A dated cut-over window and a freezeWhen users stop, when the final copy is taken and when they start again.
A written rollback planThe point of no return, who decides to roll back and how long the old server stays available read-only.
Checks that prove the move workedRow counts, totals, a set of sample records compared field by field, and each routine run once.
Who signs offThe application owner confirms it works before the old server is switched off.
Tell users and outside partiesWhat changes, when, and who to call.

07Reduce re-keying while you are in there

A move is the cheapest time to fix the routines people type by hand.

Price the routines you foundMinutes per run, runs per week, staff cost and error rate. The re-keying cost calculator does the sums.
Pick the costliest one to automate firstOne routine, with a named owner and a result someone can check.
Keep a person in charge of writesAny automated change to an old system should be previewed, approved by someone other than its author, read back and recorded.

08After the move

Finish the job properly so the old server does not linger.

Keep the old server read-only for an agreed periodThen switch it off, and keep a final backup under your retention policy.
Securely wipe or destroy retired disksIncluding backup media and any copies made for testing.
Update documentationServer names, paths, drivers, schedules, owners and the support date of the new platform.
Review backups on the new platformRun a restore test within the first month.

Where Entidex Bridge fits. Stages 1 to 3 are what a Bridge read-only survey does for a FoxPro system: it lists the tables and indexes and scans the source for the places that write to them. Nothing changes and no data leaves your site. Bridge is in development; you can try it in the sandbox or ask about a survey.

This checklist is general guidance, not advice from Microsoft or any vendor. Dates checked on 12 October 2026 against Microsoft lifecycle: SQL Server 2016 and Microsoft lifecycle: Windows Server 2016; Extended Security Update eligibility and terms are set by Microsoft. Free to share and print. From bridge.entidex.com.