In mid-2026 we moved a production ColdFusion application from ColdFusion 2018 to Adobe ColdFusion 2025 on new infrastructure: new application servers, new SQL Server instances, public traffic, and a hard cutover. It went live on schedule and under budget. The short answer from that project: a ColdFusion 2025 migration rarely fails on CFML compatibility. It fails on everything around the application, so this checklist is mostly about dependencies, reporting, DNS, and rollback. We have built and maintained ColdFusion systems since 1998, and this is the list we wish every team had before the same trip.
What should a ColdFusion 2025 migration checklist cover?
A ColdFusion 2025 migration checklist covers the whole system the application depends on, not only the code. We call that list the dependency inventory: every component outside the CFML that has to work on the first day after cutover.
Inventory every dependency, not only the app. List the database version, the reporting layer, scheduled tasks, file shares, the mail relay, certificates, and service accounts. Each one is a workstream. The ones you find mid-migration are the ones that move the date.
Put the scope boundary in writing. Decide who fixes application code that fails on the new runtime and who fixes infrastructure. On our project the client owned code compatibility and we owned the platform. Because we agreed on that before the first incident, each issue went straight to an owner. Without that agreement, every bug turns into a negotiation.
Confirm licensing before the install window. Know the edition, the license count, and where the installers and license keys are. ColdFusion licensing is not complicated. It is the kind of dependency nobody owns until the day you need it, so choose a trial-edition fallback in advance instead of improvising one.
Why does the reporting stack break during a ColdFusion upgrade?
The reporting stack breaks because the database upgrade takes it along. On our migration, the SQL Server version we moved to no longer included classic SQL Server Reporting Services (SSRS). Microsoft's Reporting Services consolidation FAQ states the change: starting with SQL Server 2025, no new versions of SSRS ship, and on-premises reporting moves to Power BI Report Server. We found out when a developer's report run failed in testing. The fix was a move to Power BI Report Server, set up the same way in test and production, with report data sources repointed and permissions rebuilt.
The lesson is bigger than SSRS. Reports run monthly or quarterly, not daily, so they fail late. List every report, name what renders it, and test that rendering path on the new stack. Do not let the first quarter-end after go-live be your test.
Testing the new servers before the DNS change
You can prove the new environment works without touching public DNS. Point test machines at the new servers with hosts-file entries and run the application against production-shaped data. That gives you real end-to-end verification, SSL bindings and integrations included, while the public still uses the old servers.
Do two things in that window:
- Lower DNS TTLs well before cutover. A 24-hour TTL found on cutover day adds a day to your rollback.
- Name the person who runs the final data sync. Seed the new database with backup and restore, then run a final offline sync during the cutover window. It is the boring, reliable pattern, and boring is what you want here.
Cutover and rollback: what earned its keep
Sequence the cutover so only one environment accepts writes at a time: take the old site offline, run the final sync, then change DNS. A cutover that leaves both environments accepting writes for an hour creates a reconciliation problem nobody budgeted for.
Put a reverse proxy on the old server. After the DNS change, clients with cached DNS keep arriving at the old address for hours or days. A proxy there forwards them to the new environment instead of serving a stale application or an error.
Keep the old environment intact for a defined period. We hold ours for about a month after cutover. Rollback is then a DNS revert, not a rebuild. Decommissioning the old servers the week after go-live saves almost nothing and sells your only clean escape hatch.
Expect a cold-start wobble. New servers have cold caches and untested timeout settings under real traffic. Our go-live produced errors from a cache cold start until we tuned a query timeout. Have someone watch error rates for the first days, with authority to tune, and count that as part of the migration, not a post-project defect.
None of this is exotic. That is the point. CFML compatibility is usually the easy part, and the checklist is what keeps everything else predictable. Before the checklist comes a harder call, how we decide which ColdFusion applications deserve a migration at all. If AI tools are part of your plan, read why we check every AI claim about old ColdFusion code against logs and tests. And if a CF2025 move is on your roadmap, our ColdFusion migration service covers how we structure the work, scope boundary and rollback plan included.