Insights OpenText
Here's the Zebra print Trade-off You Need to Know About.
OpenText Exstream on-premise supports Zebra (ZPL) label output. The Communications cloud edition doesn't. If Zebra printing is part of your process, plan for this before you migrate.
OpenText Exstream is a capable CCM platform. On-premise deployments have long history of supported ZPL output — the language that drives Zebra thermal printers — as part of a broad output channel portfolio. Labels for warehouses, dispatch, clinical environments, manufacturing floors: the on-premise stack can handle it.
The cloud edition is a different story. ZPL output is not supported. If your organisation relies on Zebra label printing as part of your document or communications process, that capability does not migrate with you when you move to OpenText Communications.
This is not a minor footnote. For organisations where label printing is operationally significant, it is a gap that needs a plan before migration begins — not after.
Why This Surfaces Late in Migration Projects
Label printing tends to be owned by operations, not by the team scoping the CCM migration. The CCM workstream focuses on customer-facing output: letters, statements, invoices, digital delivery. Labels are seen as a logistics concern, handled by a separate team, often running on infrastructure that predates the CCM platform entirely.
The result is that ZPL capability gets mapped as a current-state feature of Exstream on-premise, the cloud edition is evaluated on the document output dimensions that matter most to the project team, and the label output gap is discovered late — sometimes after go-live planning is already underway.
At that point, the options on the table tend to be uncomfortable: delay the migration, invest in a separate label management system, or accept a manual workaround that reintroduces the operational complexity you were trying to retire.
What the Gap Actually Means for Your Architecture
ZPL (Zebra Programming Language) is the standard for thermal label printing. It handles everything a label process requires: variable text fields, address blocks, lot numbers, expiry dates, compliance identifiers, logos, graphical layout elements, and — critically — barcodes and QR codes generated natively on the printer hardware.
When your CCM platform can no longer produce ZPL, one of three things typically happens:
- The label process is decoupled entirely from the CCM layer and handed to a standalone label management system — which means duplicating data, logic, and integration work
- A developer builds a custom ZPL generator that sits outside the platform — which works until it doesn't, and becomes a maintenance liability
- The label requirement is deprioritised or handled manually — which is rarely sustainable at operational volume
None of these is a good answer. The right answer is to close the gap at the integration layer, using a tool purpose-built for this kind of process orchestration.
How ENIT Flowbuilder Closes the Gap
ENIT Flowbuilder is a low-code integration platform designed for exactly this kind of process orchestration. It is not scoped to a specific output type — it can consume structured data from any source and route it to any output channel, including a properly formed ZPL stream sent directly to a Zebra printer or label management endpoint.
For label generation, a Flowbuilder flow handles the full requirement:
- Text fields populated from source data — names, addresses, product codes, batch references, expiry dates
- Graphical elements and label layout structures
- Images — logos, compliance icons, product imagery — at the correct resolution for thermal output
- Barcodes and QR codes: Code 128, EAN-13, DataMatrix, QR, and other common standards
- Well-formed ZPL output, ready for direct printing or forwarding downstream
Critically, this doesn't require replacing OpenText. The architecture is additive: Communications cloud continues to handle customer-facing document output, and Flowbuilder handles the channels the cloud edition doesn't reach. Both draw from the same upstream data event. The label generation gap is closed without introducing a new silo or a parallel CCM investment.
The Migration Conversation Worth Having Early
If your organisation is evaluating a move from Exstream on-premise to the cloud edition — or if you're already in the process — the label output question is worth surfacing now. The questions to ask:
- Which business processes currently depend on ZPL output from Exstream on-premise?
- Are those processes operationally critical, or low-volume enough to handle differently?
- What is the data source for label generation — and is it already flowing through your integration layer?
- What does a clean handoff of label responsibility look like, and who owns it post-migration?
Getting these answers before migration planning is complete is significantly cheaper than discovering the gap in UAT.
The Broader Point for Architects and Process Owners
Cloud migrations of enterprise CCM platforms are not straightforward feature-for-feature lifts. Capabilities that exist in the on-premise stack — output channels, driver support, integration patterns — may not be present in the cloud edition, and the documentation doesn't always make this obvious.
ZPL support in OpenText Exstream is one specific example. The principle generalises: before committing to a cloud CCM migration, map your current output channels against the cloud platform's actual capabilities, not its marketing materials.
Where gaps exist, they are solvable — but they need to be solved at the architecture level, with the right tooling in place, before the migration completes. Retrofitting output capability after go-live is always more expensive than planning for it.
ENIT Flowbuilder is one part of that answer. If you're working through this for OpenText, Quadient, Smart Communications, or any other CCM platform, we're happy to walk through what it looks like for your specific environment.
