When SAP sunsets the marketing stack you built on

Support for SAP Marketing Cloud ends in December 2026, and there is no in-place upgrade. You migrate — most likely to Emarsys, the platform SAP now steers customers toward — and you do it as a full rebuild of data, segments and journeys. The catch is what the replacement does not show you: an audit trail that logs who changed something but not what, and API errors hidden from the UI. Budget for the monitoring you will now own.

What exactly is sunsetting, and when?

Per OMMAX's migration analysis, support for SAP Marketing Cloud ends in December 2026. That date is the whole problem: it is a hard stop on a system sitting in the middle of your customer engagement, not a soft nudge toward a newer screen. There is no in-place path from the current product to its successor. Emarsys heads OMMAX's shortlist of four alternatives — alongside HubSpot Marketing Hub, Salesforce Marketing Cloud and Oracle Eloqua — and it is the platform SAP itself steers Marketing Cloud customers toward. Whichever name you land on, you are re-platforming, not upgrading, and the calendar is fixed by the vendor rather than by your readiness.

Why is this a migration, not an upgrade?

Because the two platforms do not share a data model, a segmentation engine or a journey format, there is no export-and-import that carries your work across intact. Contacts, consent state, field mappings, segments, automations and templates all get rebuilt and re-tested by hand. If you have lived through a platform swap sold as turnkey, you already know the distance between the brochure and the project plan; we walked through that pattern in the plug-and-play retail suite that isn't. The migration is also where you find out how well the replacement is actually documented, because you are now reading its API reference in anger — and for much of the tooling this industry runs on, there are no independent reviews to warn you first.

Where does the replacement's observability fall short?

This is the part that never shows up in a demo. Reviewers who run the platform at scale put it bluntly:

observability is lacking

and it is thin in three specific places. The change log answers two of the three questions any incident review starts with — who modified an object, and when — but records none of what actually changed. When an integrated external API fails, the platform does not surface the detailed error or the HTTP response body in its own UI logs. And a broken automation can drop into a locked fail-safe state that needs vendor support to clear, where the field workaround is to clone the automation and activate the copy, leaving duplicate deactivated flows behind in the workspace.

None of those gaps is a dealbreaker on its own. Taken together they define the operational surface you inherit the day you go live.

What does that cost you after go-live?

Add it up and you have quietly signed up to build and staff the observability the platform does not provide. Root-cause analysis on a stalled journey becomes reconstruction work: with no diff, you infer the change by correlating timestamps across the marketing platform and every system it touches. Because API error bodies never reach the UI, you either mirror those payloads into your own logging or you operate blind. Change management degrades into manual documentation — a shared spreadsheet of who changed what, because the native audit trail will not tell you. This is the same lesson as buying loyalty as a clean API and discovering you still have to build the program around it, which we covered in API-only loyalty: the vendor ships the engine, and you own everything that makes it observable and operable in production.

Isn't this just how enterprise software goes?

Partly — and that is the uncomfortable part. The roadmap you bought is the vendor's to cancel. Teams that once standardised on CloudCraze learned this when the standalone product was acquired and folded into a larger commerce suite; the same script is running now for Marketing Cloud. The real risk is not that any one of these platforms is bad. It is that a published end-of-support date converts a stable, deeply integrated system into a mandatory, multi-quarter project on the vendor's timetable, sequenced against your other commitments whether the timing suits you or not.

The way out is structural rather than tactical. Keep your customer and event data, consent state and identity in a store you control — an event bus you own — so the marketing platform becomes a subscriber you can swap rather than the system of record you rebuild. When the data and its observability live in your own architecture, the next sunset is a connector change instead of a re-platforming.

December 2026 is close enough that the sensible framing now is a data-ownership decision, not a tool-selection one. The teams that come out of this well will be the ones who used a forced move to pull their engagement data one layer inward — so that the next time a vendor publishes an end-of-support date, it arrives as a line item on a backlog rather than a fire drill spread across three quarters.