The Transport Case method for Automic deployments is the difference between a release that takes an hour and a release that takes two minutes. In environments with tens or hundreds of thousands of objects, that is not a convenience — it is the difference between deployments that fit inside a maintenance window and deployments that don’t. Part 7 of the 3C Release Manager for Automic Enablement Series looks at the alternative deployment path the product offers, what changes in the environment configuration to use it, and why it matters for any organization running Automic at real enterprise scale.
Previously in this series
This article continues the 3C Release Manager for Automic Enablement Series. If you missed the earlier parts, here is where to catch up:
- Part 1 — Snapshot Function: capturing the full state of an Automic client as a timestamped baseline.
- Part 2 — Diff Function: comparing snapshots to detect object changes and verify release transparency.
- Part 3 — Creating Environments: defining the technical connections to Automic clients that make snapshots, diffs, and deployments possible.
- Part 4 — Controlled Deployments: transporting objects between clients with automatic backups and a defined rollback path.
- Part 5 — Add Related: collecting nested workflow dependencies down to script level in a single action.
- Part 6 — Four-Eyes Principle: enforcing dual approval technically inside the deployment workflow.
With dependency-complete, governed releases in place, the next bottleneck most teams hit is pure throughput. Mature Automic clients hold tens of thousands of objects — sometimes hundreds of thousands. At that scale, the deployment method itself becomes the limiting factor.
Why the Transport Case method for Automic deployments matters at scale
The default deployment path in most Automic tooling is XML-based: every object is serialized into XML, transferred, and reimported on the target side. That works perfectly well for a handful of objects. It scales poorly the moment object counts cross into the thousands. A release of 10,000 objects that takes an hour is not unusual under the XML approach — and a release of 100,000+ objects starts to break maintenance windows entirely.
This is not a theoretical problem. It is one of the most common reasons enterprise Automic teams batch their releases into fewer, larger windows, accept long downtime, or simply avoid certain transports until they absolutely have to do them. The Transport Case method addresses the throughput problem at its root by switching to a fundamentally faster transfer mechanism.
How the Transport Case method works in the 3C Release Manager
In the 3C Release Manager for Automic, every environment can be configured to use one of two deployment paths. The difference sits in the environment definition. A standard environment — for example, one named AE24X0105XML pointing at client 105 — uses the classic XML-based path. A second environment can point at the same client but be configured with Transport Case Settings enabled, typically named with a TC suffix such as AE24X0105TC.
The system parameters at the top of the configuration are nearly identical for both. What changes is the additional connection requirement: when Transport Case is enabled, the environment needs a REST endpoint in addition to the JCP connection, because the Transport Case method operates through Automic’s REST API. The Connections check in the environment view confirms both endpoints are reachable before the environment is used.
From that point on, the difference is invisible in the user interface. Snapshots taken from a Transport Case environment look identical to XML snapshots — objects are still displayed in XML structure, the navigation is the same, and the same diff and deployment workflows apply. The acceleration happens underneath, not in the way the release manager is operated.
What the numbers actually look like
The video below shows two side-by-side comparisons from the same client 105, deploying 10,000 objects into client 106:
- Snapshot (XML): just over two minutes.
- Snapshot (Transport Case): slightly longer, because the XML structures are still captured and a Transport Case is additionally generated for each object.
- Deployment (XML): 4,098 seconds — roughly 66 minutes.
- Deployment (Transport Case): a little over two minutes.
The snapshot side is roughly comparable. The deployment side is where the Transport Case method earns its name: a 30× reduction in deployment time on a 10,000-object workload. Now extrapolate that to 400,000 objects or more — the kind of release scope that simply is not realistic under the XML approach within any normal change window.
What this changes in real Automic operations
Switching to the faster path changes four things that matter to anyone running real release schedules:
- Maintenance windows become realistic again. A 60-minute deployment that shrinks to two minutes does not just save time — it changes which releases can fit inside the operational window the business actually agreed to. That removes a common reason for postponing or batching transports.
- Large client migrations become feasible. Releases of 100,000+ objects — full client transports, environment rebuilds, large-scale consolidations — move from “theoretically possible” to operationally routine. The XML method does not scale to those volumes; the REST-based path does.
- Risk windows shrink. Every minute a release is running is a minute the target client is in a transitional state. Cutting that time by an order of magnitude directly reduces the exposure window in which something can go wrong mid-transport.
- Release frequency can increase. When transports are cheap in time, teams stop hoarding changes for the next big release window. Smaller, more frequent rollouts become possible — which is exactly the direction modern release governance points.
When to use which method
The XML-based approach is not obsolete. For small object counts, ad-hoc fixes, or environments where the REST API is not available, it remains the simpler default — fewer prerequisites, no additional endpoint configuration. The faster path is the right choice when object counts are large, when deployment time is part of the operational constraint, or when the same release will be run repeatedly across multiple targets.
One pragmatic pattern that works well in practice: define both environments side by side, pointing at the same target client, and choose the path per release. Routine maintenance changes go through the XML environment; large transports and full migrations go through the Transport Case environment. The tool handles both transparently.
Where this fits in the broader release framework
The faster path is not a replacement for the rest of the release framework — it is an accelerator underneath it. Snapshots still capture state. Diffs still surface changes. Controlled deployments still write backups and offer rollback. Recursive related-object collection still resolves dependencies. Dual sign-off still enforces approval. The Transport Case method makes all of that fast enough to apply at enterprise scale.
In other words, governance and performance stop being a trade-off. Teams no longer have to choose between a properly controlled release process and one that finishes inside the change window — they get both.
Key takeaways
- The Transport Case method is an alternative deployment path that uses Automic’s REST API instead of XML-based transfer.
- Activation is per environment: enable Transport Case Settings in the environment definition and add a REST endpoint alongside the JCP connection.
- On a 10,000-object benchmark, deployment time dropped from roughly 66 minutes (XML) to just over 2 minutes — the same workload, the same target, a fundamentally faster path.
- The acceleration is decisive at enterprise scale: large client migrations, full environment rebuilds, and 100,000+ object transports become realistic instead of impractical.
- XML and Transport Case environments can coexist, pointing at the same target client, allowing the right path to be chosen per release.
For organizations running Automic at scale, this is one of the capabilities that turns the 3C Release Manager from a useful tool into operational infrastructure.
Want to see how the product performs against your own Automic workload sizes? Schedule a free consultation to discuss your release performance requirements — or explore the full Automic course path at Tricise University to build large-scale release skills across your team.
