Going headless on a legacy CRM without freezing the business is the question every Salesforce, HubSpot, and Dynamics 365 customer is now asking. Since Salesforce launched Headless 360 on 15 April, the conversation has shifted from “should we eventually go API-first” to “how do we get there from a configured, contested, live deployment without breaking quote-to-cash for a quarter.” HubSpot and Microsoft are racing to the same place. The buyers are not the problem. The legacy estate is.
Most of the published guidance on this topic borrows from headless commerce, which has been doing this dance for half a decade. CRM is harder. A storefront has visitors who do not notice if the checkout was re-platformed last night. A CRM has thousands of internal users with muscle memory built around custom buttons, list views, and flows that may not have been documented since the year they were built. The question is not whether the strangler fig pattern works for CRM. It does. The question is which functional slice you peel off first, and what you are willing to break to do it.
What follows is a working playbook, not a marketing diagram. It assumes you already believe headless 360 is the destination and you are now trying to plan the route.
What does a phased headless CRM migration actually look like?
A phased headless CRM migration replaces the user interface and orchestration layer one functional slice at a time, while the legacy CRM continues to run as the system of record underneath. The pattern, borrowed from microservices work and popularised under the name strangler fig, sequences the migration into vertical slices like “quote creation,” “case routing,” or “renewal forecasting.” For each slice, you build an agent or API-driven workflow, route a portion of users or transactions to it, validate that the new path produces the same business outcome as the old one, then retire the legacy screen. The legacy CRM itself is the last thing to leave. In some cases it never leaves: it becomes the headless backend that the new agents speak to. The migration is finished when every business outcome can be triggered without anyone opening a browser tab pointed at the old UI.
That phrasing matters, because the alternative definitions floating around the market are not migrations at all. A wrapper that exposes the same legacy logic through a fresh API gateway is a façade, not a migration. The test is whether the screen behind the façade can be turned off without disrupting the business. If the answer is no, you have built integration debt, not progress.
Why does the strangler fig pattern fit CRM better than rip-and-replace?
Rip-and-replace assumes you can describe every workflow in the legacy system before turning it off. In a CRM that has been live for six years, you cannot. The flows that matter to the business are not the ones in the design document. They are the ones that the European finance team built in a sandbox in 2022, the validation rule that prevents a particular partner from being invoiced twice, the renamed picklist value that the data warehouse depends on. A big-bang cutover discovers these the morning after go-live, when the deals stop closing. The strangler approach surfaces them one slice at a time, while there is still a fallback. That is not a slower migration. It is the only honest one.
There is a second reason, less often discussed. CRM ownership is political. Sales, service, marketing, finance, and partner operations all hold pieces of the platform, and none of them want to be the team that loses functionality on cutover weekend. A phased migration lets each owner negotiate their own slice on their own timeline. You will move faster overall, because nobody is holding the project hostage waiting for their objections to be heard.
Which workflows should you peel off first?
The instinct is to peel off the workflow that is most painful for users. That is usually wrong. The first slice should be a high-volume, low-judgement workflow with a clean data contract and a measurable business outcome. Lead routing fits. Case auto-triage fits. Renewal date alerting fits. Quote creation does not, because it carries pricing logic that lives in a half-dozen places. Forecasting does not, because the inputs are contested across functions and there is no single ground truth. Start where the volume is high enough to prove the pattern works and the politics are low enough to let you ship in a quarter.
The second criterion is reversibility. Your first slice should be easy to roll back to the legacy path if something goes wrong, ideally with a routing flag and not a re-migration. If the only way to undo your first phase is to call a vendor and apologise, you have picked the wrong slice. Reversibility also gives the operations team something they will need on the second and third slices: confidence that the project is not asking them to bet the business on a screen they have never used.
How do you run two CRM read paths at once without confusing the business?
Dual-running CRM APIs means routing both reads and writes through both the legacy CRM and the new headless layer for a defined window, then comparing the outputs before fully cutting over. The standard pattern is to designate the legacy system as the system of record and the new layer as the system of execution, route all writes to both, and reconcile any disagreement back to the legacy record. Read traffic can be shadowed: the new layer serves the response, and a background job compares it to what the legacy system would have returned. Discrepancies are logged, not surfaced to users. Run this for thirty to ninety days per slice. The window ends when the discrepancy rate is statistically insignificant and an operations team is willing to sign off in writing. Without that sign-off, you have not finished the slice, you have just stopped paying attention to it.
The trap most teams fall into is letting dual-running become permanent. Six months in, every slice is still running on both paths, the operations cost has doubled, and nobody can articulate the exit criteria. Define the criteria up front in writing, and treat the failure to meet them as a project risk, not a delivery delay. The reason permanent dual-running feels safe is that the cost of running two systems is paid by the operations budget, while the cost of cutting over lands on a single quarter. The accounting is what kills these projects, not the engineering.
When can you actually decommission a UI-only customisation?
You can decommission a UI-only customisation when you can prove that every business outcome it produced is now reachable through an API path, and that no scheduled job, integration, or reporting query depends on the screen having been rendered. Most CRM platforms make this harder than it sounds. Salesforce flows that fire on screen interactions, HubSpot workflows that key off a record being viewed, Dynamics 365 business rules attached to a form, all of them silently disappear when the form does. Before you remove the screen, run a query against your audit logs for the past ninety days and confirm nothing critical is being triggered by user interaction with that surface. The exercise typically uncovers two or three jobs that nobody remembered existed, and at least one that nobody can identify the owner of. Resolve those before pulling the screen down, not after.
The same logic applies to dashboards and list views, which often act as informal automation. A regional manager who opens a particular list view every Monday morning is doing a workflow step the system does not record. When the list view goes away, the step goes away with it. Catch these by asking the operators, not by reading the configuration. The configuration will tell you what was built. The operators will tell you what is being used.
What breaks if you sequence the migration around the org chart?
If you sequence the migration around the org chart, you migrate Sales Cloud first because the sales VP shouts loudest, then Service, then Marketing, in a series of vertical hand-offs. That sequence ignores how data actually moves through a CRM. The shared object model is the migration unit, not the department that uses it. An Account that the sales team migrated last quarter still has cases hanging off it that service has not migrated, renewal workflows that finance has not migrated, and partner records that operations has not migrated. Every read against that Account now has to reconcile the headless layer with the legacy one. The cost of that reconciliation does not show up in the project plan, but it shows up in every report that runs against the data warehouse for the next eighteen months.
The better sequence follows the read patterns. Identify which objects are touched by the most workflows, migrate the workflows in an order that converges on those objects, and accept that one functional team will get their migration finished long before another. Politically uncomfortable, technically correct. The teams that try to keep every department on the same delivery cadence end up moving at the speed of the slowest function, which is rarely the function that matters most to revenue.
The Sirocco perspective
We have run more of these migrations in the past six months than in the previous three years combined, and the pattern that keeps emerging is that the technical work is the easier half. The harder half is governance: deciding which slice goes first, who signs off on the cutover, what evidence counts as proof that a screen can be retired. Our clients who have made the most progress did not have a better architecture. They had a smaller and more decisive steering group, and they were willing to let one functional team finish before another started. The ones who are stuck are running a parallel headless layer that nobody trusts and nobody wants to be responsible for shutting down.
If you are looking at Headless 360 and trying to work out how to phase it onto a live Salesforce, HubSpot, or Dynamics 365 deployment without a six-month delivery freeze, that is the conversation we have most weeks. Schedule a consultation and we will walk through the first slice with you.
Get in Touch
If you are mapping out a headless migration on a Salesforce, HubSpot, or Dynamics 365 estate that has to keep running through the project, tell us where you are stuck and we will share what has worked for clients in the same position.
