Retiring a CRM without losing what it knew

Most organisations running an old version of Dynamics CRM already know they have to leave it. The servers are out of support, the people who understood the customisations have moved on, and every security review adds another line to the risk register. What stops them is rarely the new platform. It is the ten or fifteen years of customer history sitting in the old one.

That history still gets used. A complaint from years ago resurfaces, or an auditor asks what was said to a client before a product changed. Switch the CRM off and those questions have nowhere to go.

Why we kept the database

The application and the data it holds age differently. The application needs servers, patches, licences, integrations and somebody who can fix it at two in the morning. The data only needs to stay safe and searchable.

We have been helping a financial services business separate the two. Their CRM environment could not be maintained and the servers were due to be decommissioned. Migrating many years of records into the new platform was possible, but it would have meant reworking data that nobody intended to change again, at a cost out of proportion to how often it is read.

So we kept the database and retired everything around it.

What we built

The design is deliberately small. The portal reads the CRM's SQL database where it already sits, through a least-privilege, read-only account that sees the data through the CRM's own filtered views. A lightweight web portal sits on top of it: a .NET API that exposes only the entities people actually search, which are contacts, accounts, cases, activities and notes, and an Angular front end for search, filtering and drill-down.

Nobody gets a new password. Sign-in is through the organisation's existing Entra ID, and access is limited to members of one security group, so revoking someone's access is the same act as it is everywhere else in the business. The portal never writes to the database. Once it is live, none of the CRM's application components are needed. Deployment runs from the client's own DevOps pipelines onto its own web servers, and because the portal holds no data of its own there is nothing new to back up.

Databases built by a CRM are not always keyed the way a modern data-access library expects, so we profiled the real schema before writing a line of API code, and every query is a named, parameterised SQL script kept in source control rather than a stored procedure hidden in the database. Finding that out during design costs a conversation. Finding it out in the second sprint costs the sprint.

The exclusions list did the most work

The document that mattered most in this engagement was the list of what we would not do. No data cleansing. No deduplication. No migration into the new platform. No reporting beyond search and detail views. No bulk export. No public access.

Every item on that list was a reasonable request that somebody would have made in week three. Writing them down before the build started keeps the portal cheap to run and made it quick to deliver, and it kept the conversation about each one where it belongs: as a separate decision with its own cost, taken later if it is needed at all.

What this changes for the business

The portal is now running in the client's test environment against live CRM data and is heading to production. Once it is released and signed off, the old application servers can go, and with them the patching and the licences. Only the database server stays, read-only. The history will stay searchable by the people who need it, under the same sign-in and access rules as everything else. The new CRM starts clean, because nothing has to be forced into it to preserve the past.

Our work on legacy modernisation usually starts with that question, and the platform choices behind it are covered under governed data platforms.

Structured records are the easier half of a retirement. The documents that sat beside them are harder, and that is the subject of a later piece.