Retiring an on-prem Dynamics CRM server: archive the history first

What does end of support mean for an on-prem Dynamics CRM server?#

End of support for an on-premises Dynamics CRM version means Microsoft stops shipping security updates and fixes for it, while the server keeps running exactly as before. Nothing is deleted on the date, which is why many IT teams let the machine sit. The exposure grows quietly: an unpatched CRM server, often on an aging Windows Server and SQL Server stack, still holds years of customer conversations.

Dates differ by release, so check Microsoft's lifecycle pages for the exact version you run, whether that is Dynamics CRM 2016 or Dynamics 365 Customer Engagement (on-premises). Check the operating system and SQL Server version underneath it too. The practical deadline is whichever of the three ends first, or the date your infrastructure team wants the hardware back.

For a distributor, wholesaler or 3PL, that CRM usually holds more than contacts. Customer service cases, delivery complaints, quote follow-ups and account notes record how the business handled problems, and that trail is hard to rebuild once the server is gone.

What history lives in an on-prem Dynamics CRM deployment?#

An on-prem Dynamics CRM deployment keeps almost everything in its SQL Server organization database, next to a configuration database that describes the deployment itself. That covers standard entities, the custom entities a partner built over the years, notes, and in many deployments the attachment files too.

Count each record family below before scoping the retirement. Migration plans tend to focus on accounts, contacts and open opportunities and quietly skip the rest.

The archive checklist before the server goes dark#

The archive checklist starts with the databases and works outward to the pieces that live elsewhere or depend on them. Work through it while the server, its service accounts and the people who administered it are still available.

• 1Take a full SQL Server backup of the organization database and the configuration database, then restore both on a separate server to prove the backup works.
• 2Confirm where attachments live: inside the database, or offloaded by an add-on to SharePoint, cloud storage or a file share. Export the files from wherever they actually sit.
• 3Check whether auditing was enabled, for which entities, and whether older audit logs were ever deleted. Export audit history before any cleanup job runs.
• 4Document how email was tracked: the Outlook client, the Email Router or server-side synchronization. Tracked messages sit in CRM; untracked mail stays only in mailboxes.
• 5Export the managed and unmanaged solutions so custom entities, option set labels and field definitions can be read later.
• 6Record row counts per entity, date ranges and the exact CRM build, and store that summary with the backup.
• 7Save a readable copy of the core entities, such as cases with their notes and activities, as CSV or JSON.

Migrate to Dynamics 365 online, archive, or keep it read-only?#

The choice between migrating, archiving and keeping a read-only server depends on which records people still open every day and which only need to survive. Most companies end up with a mix: active records move, the full history is archived, and the old server stays read-only for a defined period.

If your migration partner proposes a cutoff date for history, ask what happens to everything older. A specific answer, such as a verified backup plus readable exports owned by IT, beats an assumption that someone will deal with it later.

How to keep an old Dynamics CRM read-only without breaking the trail#

A read-only Dynamics CRM is created by changing security roles and switching off automation, not by stopping services. Give users a role with read privileges only, deactivate workflows and plug-in steps that write data, and stop email synchronization so nothing new is tracked into old records.

Isolate the server on the network, limit access to a named group, and document the service accounts. Put the read-only server's retirement date on the IT calendar with an owner, because a temporary server nobody owns tends to become permanent and unpatched.

Illustrative: a distributor retires its CRM server#

Illustrative: a fictional industrial distributor runs customer service on an on-prem Dynamics CRM 2016 server. Cases record backorders, damaged shipments and pricing disputes, and inside sales reps track email through the Outlook client. The company is moving to Dynamics 365 online with its ERP partner.

The partner's plan migrates accounts, contacts and open cases. The IT lead inserts an archive phase first: a verified SQL backup, an export of every closed case with its notes and activities, attachments pulled from a file share an old add-on had used, and the audit log for the case entity. The old server then runs read-only until customer service signs off, and is shut down.

Later, during a company-wide records inventory, the closed-case archive turns out to be the most complete record of how the business resolved shipping exceptions. Because it exists in readable form, the company can describe it in a metadata-only fit check without restoring anything.

How SourceX approaches a retiring CRM#

SourceX treats a retiring CRM as a records question before it is a licensing question. In the Supply step of the SourceX five-step transaction, a company describes systems, record families and date ranges as metadata only; no files are shared during the initial assessment. Rights, Preparation, Approval and Delivery follow only if the supplier chooses to continue.

Archive notes from the retirement, such as backup dates, row counts and the export method used, make provenance far easier to document in a SourceX Evidence Packet if a package proceeds. Data is licensed, not sold outright, and the company keeps ownership of its records.