GTM Stack Architecture
September 5, 2026 · 6 min read · by Ananda Narasimhan
Search for "GTM stack modernisation" and every result is a list of tools to buy. That is the wrong artefact. A company with a stack old enough to need modernising does not have a gap in its tooling. It has fifteen tools, four of which are dead, three of which disagree about what a lead is, and an integration layer nobody drew. The work is subtraction before it is anything else.
This is the retirement order we use. It is a sequence, not a checklist, because each step removes dependencies the next step would otherwise have to work around. Done out of order, you end up modernising things you were about to delete.
Start with workflows, not licences. Every scaling stack accumulates automations built for a campaign, a rep, or a quarter that has ended: a Marketo smart campaign that still rescores leads on a webinar from 2023, a Zapier zap that writes to a field the CRM no longer displays, a HubSpot workflow that re-enrols contacts every time a sync job touches them. They are invisible on the invoice and they are the most common cause of "the data changed and nobody knows why."
The test is simple. Pull the list of active automations from every system, and for each one, name the owner and the outcome it produces today. Anything with no answer to either question gets paused, not deleted, for thirty days. If nothing breaks and nobody asks, it goes. In most stacks this retires a third of the automation inventory before a single tool is touched, and it removes the write conflicts that would otherwise corrupt the next step.
A field written by two systems is not a field, it is an argument. Lifecycle stage set by both the MAP and the CRM. Lead source overwritten by the enrichment tool on every refresh. Owner reassigned by a routing rule and then by a rep, in a loop. These are what make every dashboard downstream untrustworthy, and they are why sales and marketing walk into the same board meeting with different numbers.
Retire the second writer, not the field. Decide which system owns each contested field, make every other system read-only on it, and document the decision in one place. This is unglamorous and it is the single highest-return step in the sequence, because it fixes the measurement layer without buying a measurement tool. Our CRM hygiene audit covers how to find the contested fields; the RevOps data janitor workflow is how we keep them from coming back.
Now the licences. But before deciding which application to replace, look at how the applications are connected. A stack of eleven tools wired directly to each other has up to fifty-five integrations to reason about, most of them native connectors configured once by someone who has since left. Every tool swap in that topology is a project, because it touches every connector on the way in and out.
Retire the direct wiring in favour of a defined integration layer, whether that is a warehouse-plus-reverse-ETL pattern, an iPaaS such as n8n or Make, or simply a hub-and-spoke through the CRM. The point is that the next tool change touches one integration instead of ten. This is the step most teams skip, because it produces nothing visible. It is also the step that makes the rest of the modernisation cheap instead of recurring. The longer version of this argument is on our GTM stack architecture page.
Only now do you evaluate applications, and the first cut is not features. It is exit. Can you get your own records out of the platform cleanly, on a schedule, in a shape another system can read, without a services engagement? A tool that fails that test is a decision you made once and pay for on every future change, and it is the tool to retire first among the ones that still technically work.
This matters more in 2026 than it did five years ago because the next layer of the stack is agentic. Agents that enrich, route, summarise and follow up need clean, accessible records far more than they need clever prompts. A closed data model caps what any agentic workflow on top of it can do, however good the model is.
The CRM goes last, or it does not go at all this cycle. Changing it changes everything downstream, so modernising activation and measurement around a CRM you intend to replace in six months is work you will do twice. If the CRM genuinely has to move, it moves first and everything else waits. If it does not, it stays, and the four steps above will have removed most of the reasons people thought it needed replacing.
In practice, the retirement question for the CRM is rarely about the platform. It is about whether the object model can carry the next stage of the business: multi-product, multi-currency, a second motion such as PLG alongside sales-led. At Series A that is almost never a real constraint. At Series C it sometimes is, and the honest answer comes out of the entity-model review, not the vendor demo.
Run in this order, modernisation is a quarter of focused work. Weeks one and two are inventory and the automation pause. Weeks three to five settle field ownership and ship the integration layer. Weeks six to ten replace whatever still needs replacing, which by then is usually one or two tools rather than the six that were on the original list. The year-long migration most teams brace for is what happens when the sequence runs backwards, buying first and discovering the dependencies afterwards.
If you are not sure which of the five layers is actually constraining you, the GTM health check returns a scored answer for free. It is the same diagnostic frame we open a paid engagement with.