EPCIS 1.2 vs EPCIS 2.0: what actually changes, and do we have to migrate a decade of XML?

You have a decade of EPCIS event exports. They are 1.1 and 1.2 XML — SOAP-era documents, sitting in an archive, occasionally pulled for an audit, otherwise untouched. Now a retailer's Sunrise 2027 request and a "move to EPCIS 2.0" line in someone's roadmap have collided on your desk, and the question underneath both is the one nobody on the call will say out loud: if we move to 2.0, do we lose our history?

Short answer: no — but only if the migration is done to a bar most vendors will not clear. This is the read that lets you tell the difference between a real 2.0 capability and a checkbox, and it leads with the number that actually decides the project: not the standard version, but whether a decade of your own events survives the move intact and provable.

Lead with the cost, not the version number

The reason to care about EPCIS 2.0 is not that 2.0 is newer. It is that your existing history is an asset you have already paid for — every recall you can reconstruct, every audit you can answer, every traceback that does not turn into a week of archaeology depends on those events staying readable. A migration that silently drops fields, mangles a timezone, or rounds a quantity does not just cost you the migration. It costs you the archive, and you find out at the worst possible moment: mid-audit, when the record you reach for no longer matches the record you filed.

So the framing that survives a steering committee is not "we upgraded to EPCIS 2.0." It is: "a decade of our event history is now readable through a modern interface, and we can prove — file by file — that nothing was lost in the move." Everything below is in service of that second sentence.

What EPCIS 2.0 genuinely adds

EPCIS 2.0 (ratified 2022) is not a rewrite of the event model you already know. The five event types you export today — Object, Aggregation, Transaction, Transformation — are still the five event types. What 2.0 adds sits in three buckets, and it is worth separating the load-bearing additions from the cosmetic ones.

1. A JSON / JSON-LD serialization alongside XML. This is the change everyone leads with, and it is real but narrower than it sounds. EPCIS 2.0 defines a JSON-LD representation of the same event model. JSON-LD matters because it is web-native — it drops into a <script type="application/ld+json">, it is what modern tooling and increasingly machine readers expect, and it carries a @context that makes the event self-describing. But note what this is not: it is not a new data model. A well-formed 2.0 JSON event and the equivalent 1.2 XML event describe the same thing. The serialization is the wrapper, not the content.

2. A REST capture-and-query interface with an official OpenAPI definition. This is the genuinely load-bearing addition, and it is the one your platform team will care about most. EPCIS 1.2 gave you a capture interface and a SOAP-flavored query interface that most of the industry implemented as a bespoke integration each time. EPCIS 2.0 defines a proper REST API — capture endpoints, query endpoints, subscriptions, pagination, standardized error handling — with an official OpenAPI specification you can pin as a dependency and generate against. This is the difference between "we can exchange EPCIS documents" and "we can call each other's systems." For a brand orchestrating events across co-manufacturers, that interface is the thing that makes an event layer operable rather than an archive you dump into.

3. GS1 Digital Link as a first-class identifier syntax, plus sensor and IoT support. EPCIS 2.0 lets identifiers appear in GS1 Digital Link URI form — the same web-resolvable form your Sunrise 2027 2D mark can carry — so the identifier in your event and the identifier under your barcode are the same object, not two representations you reconcile. 2.0 also adds sensor data (the sensorElement, and a new AssociationEvent for pairing a sensor or reader to an asset) and persistent disposition. For a cold-chain or regulated-goods brand the sensor support is material; for a dry-goods CPG it is mostly future-proofing.

The honest cosmetic column. Some of what gets sold as "2.0 value" is repackaging. JSON is not more expressive than the XML it replaces. A vendor saying "we support 2.0" because their system can emit a JSON blob has told you almost nothing about whether they can carry your history across the move. Which brings us to the only test that matters.

"We support 2.0" is worthless without a lossless round-trip

Here is the sentence to put in front of any vendor, internal or bought: support for EPCIS 2.0 is not a claim about JSON. It is a claim about fidelity.

The migration that protects your archive is a lossless round-trip: your 1.1/1.2 XML translated into 2.0 JSON-LD, and translated back, arriving byte-faithful to what you started with — every extension field, every timezone offset, every quantity and unit, every vocabulary URI preserved. If translate(XML → JSON → XML) does not return you the original, the migration is lossy, and the loss is in your history whether or not anyone measured it.

The reason this bar is high is that real EPCIS exports are full of the things careless converters drop:

• User extensions and custom vocabularies. A decade of exports almost certainly carries brand-specific or partner-specific extension fields. These are exactly the elements a naive converter silently discards, because they are not in the base schema.
• Master data (the EPCISMasterData / vocabulary section). The location and business-step definitions that make your events mean something live here. Drop them and the events survive but stop being interpretable.
• Timezone and precision. EPCIS event time carries an offset. A converter that normalizes everything to UTC has changed your record — and in a traceback where "before or after the contamination window" is the whole question, a shifted timestamp is a wrong answer.

None of this is exotic. It is what your archive is actually made of, and it is why "supports 2.0" and "preserves your history" are different claims that vendors deliberately blur.

The bar you can hand an auditor: a per-job fidelity report

The demonstrable version of "nothing was lost" is not a promise. It is an artifact: a per-job round-trip fidelity report. For every file you migrate, the report states what was read, what was written, and that the round-trip reconstructed the source — with the specific fields, counts, and any deliberate normalizations named explicitly. That report is what you hand an auditor who asks "how do you know your 2.0 archive matches the 1.2 records you filed?" The answer is not "our vendor said so." It is a document, per file, that a skeptic can check.

This is the bar we build to. translate reads EPCIS 1.1 / 1.2 / 2.0 XML into EPCIS 2.0 JSON-LD and produces that per-job fidelity report; the projection then validates against the official GS1 EPCIS 2.0 JSON schema, pinned by sha256 digest so the schema you validated against is a fact, not a moving target. You can read the standard yourself — the event model, the serializations, and the interface bindings are all public in the GS1 EPCIS 2.0 standard. We conform to it; we do not stand above it.

The proof line. The translate and validate doors are live — POST your own XML to https://epcis.dev/translate and the projection to /validate, one curl each — and you can round-trip your own file today. No conformance attestation has ever been issued, and none is claimed. The durable, hosted write path is a named entry in the open P0 ledger.

Do you have to migrate at all?

Worth saying plainly, because the answer is often "not the way the roadmap implies." Your 1.2 XML archive does not stop being valid EPCIS the day 2.0 exists; a well-formed 1.2 document is still a well-formed record of what happened. You do not have to bulk-convert a decade of files to be "compliant." What forces the move is not the archive — it is the interface: the moment a partner, a retailer program, or your own new capture flow wants events over the 2.0 REST API in JSON-LD, you need translation at the boundary, not a museum project on the back catalog. Migrate the flow that is live. Keep the archive as-is, and translate on demand — provably — when someone reaches for it.

Run it on one of your own files

The way to settle whether any of this is real is to stop reading and run it:

1. Take the read. The segment-specific read of what Sunrise 2027 actually requires of a GTIN owner, and where the EPCIS 2.0 interface — not the archive — is what forces your hand. Free, no gate: Sunrise 2027 for brand owners.
2. Round-trip a real export. Hand a genuine 1.2 XML file to your platform engineer: POST it to https://epcis.dev/translate, POST the projection to /validate, and read the per-job fidelity report on your own data. The developer lens on the same spine, with the interface details, is epcis.dev.
3. Then, the ask. Your capture workspace is provisioned from the seat list, in order.

Put me on the seat list

The interview that produces your program-office read is live: get started — your address first under the one-message promise, then questions that branch on your answers, ending in a written read that locks. The lighter thing you can leave is the list.

Put me on the seat list → Manufacturer / brand — you pack it out and you own the GTIN

The seat-list promise, exactly: your capture workspace is provisioned from this list, in order — one email when your seat is ready, one, not a drip campaign. Nothing else, ever. If we stop working on this, you get one message saying so and your address is deleted. The named human sender and the verified sending address are a launch gate — P0-V4 in the open P0 ledger; the message is not sent until both exist.

---

llms.txt entry (append under ## Pages on visibility.cloud)

---