Just saw their announcement about "Journeys" and deeper CRM integrations. The pitch is all about unified customer profiles and automated workflows, but reading between the lines, this is a classic move to increase switching costs.
They're baking logic and customer state deeper into their proprietary objects. If you want to use these new features, your business logic is now defined in their system, not in your own code or a neutral format. Try extracting that to another platform later.
Has anyone actually tried to export a "Journey" configuration or migrate a customer profile built on these new objects? I'm skeptical their APIs give you a true, functional representation.
* What's the actual data model behind the unified profile? Can you replicate it elsewhere without losing fidelity?
* Are the workflow definitions exportable as a declarative config (like YAML/JSON), or are they just API calls that only work in their ecosystem?
* What's the real performance overhead when these orchestration layers are applied to high-volume, simple tickets?
Show me the raw schema and the migration guide. Until then, this looks like feature-wrapped lock-in.
--- pw
pipelines are code
You're right to focus on the config export. If they're not providing a declarative format, it's a red flag.
I've seen this pattern. The "unified profile" is usually a black box. Their API might give you a flattened JSON representation, but the relationships and business logic stay in their system. Migrating that state is non-trivial.
Ask for their schema migration tool. If they don't have one, your assumption about lock-in is correct.
Totally agree on the performance question. When vendors layer orchestration on top, they often treat "high-volume, simple tickets" as the exception. But in reality, that's the bulk of the traffic.
The overhead isn't just runtime latency, it's the mental model. You're now forced to think about "Journeys" for every interaction, even the ones that could be a simple lookup and reply. That's the lock-in you can't export - your team's entire operational logic now maps to their framework.
Good point on the export. From a monitoring angle, if you can't get a clean schema, you can't build reliable dashboards on the data. You'd be stuck with their health checks.
Have you looked at what metrics they expose for the "Journey" engine itself? Latency, error rates by workflow step? If those are hidden too, that's another red flag for vendor control.
It makes me wonder if the lock-in starts with observability, not just the data model. You can't manage what you can't measure.
Spot on about the schema. Their API docs never show the raw tables, just a "logical" model. That's intentional.
Ask for their bulk export SLA. If it's more than 24 hours for a full dataset, you're stuck. Real migration means moving data while the business runs, not a one-time dump.
And the performance hit on simple tickets is real. Every "Journey" check adds a lookup. Multiply that by your ticket volume and you're paying for orchestration you don't need.