Legacy-GTM Sprawl: Building One Compliance Data Layer Across SAP GTS, Oracle GTM, and OneSource, Without Ripping Them Out

What is legacy-GTM sprawl, and how do you fix it without a rip-and-replace?

Legacy-GTM sprawl is the condition where classification, duty, and origin data are trapped in separate, non-reconciling instances of SAP GTS, Oracle Global Trade Management, and Thomson Reuters OneSource that grew up around different acquisitions, regions, and ERPs. You fix it by laying one programmatic compliance data layer across those instances, treating each as a system of entry rather than the system of truth, so every instance reads one consistent classification and tariff record instead of holding its own divergent copy. GingerControl is an AI-powered trade compliance platform that classifies products, computes the full U.S. tariff stack, and tracks policy changes; its AI Integration service and Trade Compliance OpenAPI give a team the building blocks to assemble that layer over the legacy stack rather than under it.

Can you unify SAP GTS, Oracle GTM, and OneSource without migrating off them?

Yes. The augment-not-replace approach leaves the legacy GTM instances in place to keep doing what they already do, screening, document generation, filing handoff, and adds a thin data layer above them, built from AI Integration and the OpenAPI, that owns the authoritative HTS, origin, and tariff record and serves it back to each system. No migration, no big-bang cutover, no re-validation of every downstream filing path.

TL;DR

Legacy-GTM sprawl is what happens when a multinational ends up running two or three legacy global-trade-management platforms at once, SAP GTS in one region, Oracle GTM from an acquisition, Thomson Reuters OneSource in another business unit, each with its own item master, its own classification of the same part, and its own duty logic, and none of them reconciling. The instinct is to consolidate onto one platform, but a rip-and-replace of a system that touches live customs filings is high-risk, multi-year, and the regulatory clock does not wait: SAP ended mainstream maintenance for SAP GTS 11.0 on December 31, 2025, and Oracle has announced that Premier Support for on-premises Transportation Management and Global Trade Management is ceasing, with the 6.5.x line the last on-premises release (SAP via Rimini Street; Oracle Support Doc 2966726.1). For a global trade compliance director governing 80,000 to 250,000 active parts across three legacy GTM instances and a dozen ERP plants, the augment-not-replace path is to build one compliance data layer over the stack rather than under it. GingerControl, an AI-powered trade compliance platform that classifies products, computes the full U.S. tariff stack, and tracks policy changes, gives teams the building blocks for that layer, the AI Integration service and the Trade Compliance OpenAPI, so the authoritative classification record lives in one place and every legacy instance reads from it, instead of each instance being re-platformed at once.

Last updated: June 2026

Why does legacy-GTM sprawl happen, and why is it so hard to unwind?

No one sets out to run three global-trade-management platforms. Sprawl accumulates. A company standardizes on SAP GTS in North America, acquires a business already live on Oracle GTM, inherits a OneSource deployment in a European entity, and a decade later the trade-compliance function is governing the same products across instances that were never designed to agree. Each instance was a reasonable decision in its moment. Together, they are the problem.

The reason it is hard to unwind is that a GTM instance is not a passive database. It is wired into live customs filing, denied-party screening, license determination, and document generation. Every one of those paths has been validated, audited, and connected to a broker or a filing channel. Ripping one out means re-validating all of it, which is why consolidation projects routinely run multi-year and stall when a reorganization or a budget cycle interrupts them.

The conventional answer, migrate everyone onto one platform, collides with three realities:

Reality	Why it blocks rip-and-replace
Regulatory clock does not pause	SAP GTS 11.0 left mainstream maintenance on December 31, 2025; after that date SAP no longer ships tax, legal, and regulatory updates for that release (Rimini Street summary of SAP timelines). A two-year migration cannot be the only answer to a compliance gap that is live now.
Filing paths are load-bearing	Each instance feeds entry filing through a broker or channel that has been validated against your records. A cutover re-opens every one of those validations at once.
Vendor roadmaps are diverging	Oracle is moving on-premises OTM/GTM customers toward cloud, with 6.5.x as the last on-premises release (Oracle Support Doc 2966726.1); Thomson Reuters launched ONESOURCE+ in November 2025 as an AI-powered network layer (Thomson Reuters press release). Betting the whole program on one vendor's migration path concentrates risk.

The augment-not-replace thesis starts from a different premise: you do not need every system to agree internally. You need every system to read from one authoritative record. That is a far smaller problem, and it does not require touching the filing paths at all.

Quotable insight: A legacy GTM instance is a system of entry, not a system of truth. SAP GTS, Oracle GTM, and OneSource were each built to do something with classification data, screen it, file it, document it, not to be the single authoritative source of it. Legacy-GTM sprawl is not three databases disagreeing; it is three systems of entry with no system of truth above them. Add the layer of truth and the disagreement stops mattering.

How do you build one compliance data layer over the legacy stack?

The data layer is not a fourth GTM platform. It is a thin, programmatic record that sits above SAP GTS, Oracle GTM, and OneSource, owns the authoritative HTS code, country of origin, customs value reference, and full tariff stack for each part, and serves that record back to every instance through an API. GingerControl does not sell a packaged "data layer" product; it provides the building blocks, the AI Integration service and the OpenAPI, that a team assembles into one. The architecture has three moving pieces.

1. One authoritative classification and tariff record. The GingerControl OpenAPI takes a product description plus country of origin and returns a 10-digit HTS code with the full U.S. tariff stack (General/MFN, Special, Section 301, Section 232 with steel and aluminum pour-country detail, Section 122, and Chapter 99 entries) in a single call, grounded in GRI logic, Section and Chapter Notes, and CROSS rulings. That record, not any individual GTM instance, becomes the source of truth.

2. A reconciliation pass that reads what each instance currently holds. Before the layer serves a single answer, it has to know where the instances disagree. The same part carrying three different HTS codes across SAP GTS, Oracle GTM, and OneSource is re-derived once through GRI reasoning, and the divergence is surfaced as an exception for a human to resolve, not silently overwritten.

3. A serve-and-write-back contract. Each legacy instance reads the authoritative record through the API and keeps doing its job, screening, document generation, filing handoff, unchanged. The AI Integration service builds the connectors that wire this into bespoke import/export systems and ERPs that go beyond standard SaaS connectors.

Here is the architectural contrast that defines the approach:

Approach	Legacy GTM instances	Source of classification truth	Filing paths re-validated	Time to first reconciled record	Regulatory-clock risk	Vendor lock-in	Audit trail
GingerControl data layer (augment)	Stay in place as systems of entry	One authoritative record served by API	No	Weeks (API plus reconciliation pass)	Low; legacy stays compliant while the layer is built	Low; layer is vendor-neutral over the stack	Reasoning chain per record, one consistent basis
Rip-and-replace migration	Decommissioned, replaced by one platform	The new platform	Yes, all at once	Multi-year program	High; gap persists until cutover	High; concentrated on one platform	Depends on the new platform
Status quo (stitched legacy GTM)	Stay, each as its own system of truth	None; each instance holds its own	No	Never reconciles	Persistent; no single owner of accuracy	Distributed across three vendors	Fragmented across three exports

Bottom line: For a trade-compliance director governing 80,000-plus parts across SAP GTS, Oracle GTM, and OneSource at once, building one data layer over the stack delivers a reconciled, audit-ready classification record in weeks while the legacy instances keep filing, whereas a rip-and-replace migration leaves the disagreement live for the multi-year duration of the project. A single-platform migration is the right call only when the organization has already committed to one vendor's roadmap and can absorb a full re-validation of every filing path.

Why "system of entry, not system of truth" changes the reconciliation problem

The reframe matters because it changes what you are trying to fix. If you believe SAP GTS, Oracle GTM, and OneSource each ought to be correct on its own, then sprawl is an unsolvable governance war, three teams, three item masters, three classification histories, all defending their version. If you accept that none of them is the system of truth, the war ends. The instances do not have to agree with each other. They only have to agree with the layer.

This is also where reasonable care comes back into focus. Under 19 U.S.C. 1484, the importer of record is responsible for using reasonable care to enter, classify, and value imported merchandise. CBP's Informed Compliance Publication on reasonable care frames it as an operational standard, and 19 CFR Part 163 requires the supporting records to be kept for five years from the date of entry. When the same part is filed under one HTS code in the SAP GTS region and a different code in the OneSource region, an auditor does not have to prove which one is wrong, the inconsistency itself is the finding. A single authoritative record, with one documented reasoning chain behind it, is the cleanest demonstration of reasonable care a multi-instance shop can produce.

CBP's Reasonable Care guidance puts the obligation plainly:

"The importer of record is responsible for using reasonable care to enter, classify and determine the value of imported merchandise and to provide any other information necessary to enable U.S. Customs and Border Protection to properly assess duties, collect accurate statistics and determine whether any other applicable legal requirement is met." (CBP, Reasonable Care Informed Compliance Publication)

A data layer does not relieve the importer of that duty. It does something more useful: it makes the duty satisfiable at scale, because there is one record to stand behind instead of three to reconcile under audit. GingerControl is an HTS Classification Researcher; it follows the same reasoning process a licensed customs broker uses, GRI analysis, Section and Chapter Note review, and CROSS ruling research, and produces audit-ready documentation that supports the classification decision. The final 10-digit determination and entry filing remain the customs business of the importer or their licensed broker (CBP Ruling HQ H290535; CBP Ruling HQ H350722, January 16, 2026). The layer is the research foundation that every legacy instance reads from, not a replacement for broker judgment or for the GTM systems themselves.

What the reconciliation actually looks like across three instances

The most concrete way to see augment-not-replace is to follow one part. Suppose a wiring harness assembly is active in all three systems: HTS code A in SAP GTS (inherited from the original North American classification), HTS code B in Oracle GTM (set during the acquisition that brought the instance in), and HTS code C in OneSource (classified independently by the European entity). All three feed live filings. None of the teams knows the others disagree.

The data layer resolves this in a defined sequence:

1. Pull current state. The reconciliation pass reads the part's classification, origin, and value from each instance and flags that three codes exist for one part.
2. Re-derive once. The part is classified one time through GRI logic via the Classifier or OpenAPI, producing a single candidate code with a full reasoning chain, not a vote among the three legacy answers.
3. Surface the divergence as an exception. Where the re-derived code differs from any instance, a human reviewer sees the conflict, the reasoning, and the relevant CROSS rulings, and confirms the authoritative code. The system asks before it overwrites; it does not silently pick one.
4. Serve the one record back. SAP GTS, Oracle GTM, and OneSource each read the confirmed code through the API. Their screening, document, and filing functions run unchanged, now on a consistent input.
5. Hold the line over time. Because the authoritative record is owned by the layer, the next time any instance drifts, the divergence reappears as an exception rather than disappearing into a silo.

For a team running this across an 80,000-to-250,000-part catalog, the OpenAPI batch endpoint processes up to 200 items per request and the standard production tier handles 200,000-plus classifications per day, so the initial reconciliation pass is a scheduled job, not a multi-year manual project. The point is not speed for its own sake; it is that the legacy stack never goes dark while the truth layer is built on top of it.

How does this compare to the rip-and-replace migration most vendors propose?

Most platform vendors answer legacy-GTM sprawl with their own migration: consolidate onto our cloud, decommission the rest. That is a legitimate strategy when an organization has already chosen a vendor and can fund a full program. But it answers a different question than the one a compliance director facing a live maintenance deadline is actually asking, which is "how do I get to one consistent, defensible classification record before my next audit, without taking my filing paths offline?"

The augment-not-replace layer and the migration are not mutually exclusive. The layer is the faster path to a reconciled record, and it is also the lower-risk bridge if you do eventually consolidate, because once one authoritative record exists, any future migration imports clean, single-sourced data instead of carrying three divergent histories into the new platform. You can build the layer now and decide on consolidation later, on your own clock rather than the vendor's.

GingerControl's role in this is deliberately narrow and honest: it supplies the classification truth and the integration plumbing, the Classifier, the OpenAPI, and the AI Integration service, and leaves SAP GTS, Oracle GTM, and OneSource to do the operational work they already do well. GingerControl helps companies build in-house AI-augmented compliance capabilities, from process consulting to custom integration, rather than selling a platform that demands you abandon the systems you have validated.

Frequently asked questions

What is legacy-GTM sprawl and why does it create audit risk?

Legacy-GTM sprawl is running multiple legacy global-trade-management platforms at once, typically SAP GTS, Oracle GTM, and Thomson Reuters OneSource, each with its own item master and its own classification of the same parts. It creates audit risk because the same product can be filed under different HTS codes in different regions, and under 19 U.S.C. 1484 that inconsistency is itself a reasonable-care finding. GingerControl addresses the root cause with its AI Integration service and OpenAPI, which let a team serve one authoritative classification record to every instance instead of reconciling three.

Can I unify SAP GTS, Oracle GTM, and OneSource without migrating off them?

Yes. The augment-not-replace approach builds a thin compliance data layer over the stack that owns the authoritative HTS, origin, and tariff record and serves it back through an API, leaving each legacy system in place to screen, document, and file as it already does. For a director governing 80,000-plus parts across three instances, this delivers a reconciled record in weeks rather than the multi-year timeline of a platform migration. GingerControl's OpenAPI and AI Integration service supply the classification truth and the connectors that wire it into bespoke GTM and ERP systems.

How does GingerControl decide the authoritative HTS code when three systems disagree?

GingerControl does not vote among the three legacy answers. Its HTS Classification Researcher re-derives the code once through GRI logic, surfaces the divergence as an exception with the full reasoning chain and relevant CROSS rulings, and asks a human reviewer to confirm before overwriting. For a compliance team reconciling tens of thousands of conflicting parts, this is the difference between a defensible single record and an arbitrary tie-breaker; the system asks before it classifies rather than guessing.

Does building a data layer replace my customs broker or my GTM platforms?

No. GingerControl is an HTS Classification Researcher that produces audit-ready documentation supporting the classification decision; the final 10-digit determination and entry filing remain the customs business of the importer or their licensed broker, per CBP Rulings HQ H290535 and HQ H350722. The data layer also does not replace SAP GTS, Oracle GTM, or OneSource, it feeds them one consistent record so they keep doing their operational work on better input. GingerControl augments both broker judgment and the legacy stack rather than displacing either.

What happens to my records and reasonable-care position under this approach?

A single authoritative record with one documented reasoning chain is the cleanest reasonable-care demonstration a multi-instance shop can produce, because an auditor sees one consistent classification rather than three conflicting filings. 19 CFR Part 163 requires those supporting records to be kept five years from the date of entry, and GingerControl's audit-ready reports preserve the GRI citations, Section and Chapter Notes, and CROSS references behind each code. For a team facing a Focused Assessment across multiple entities, that consistency is what turns a finding into a non-issue.

How fast can a reconciliation pass run across a large multi-instance catalog?

GingerControl's OpenAPI batch endpoint processes up to 200 items per request, and the standard production tier handles 200,000-plus classifications per day, so an initial reconciliation across an 80,000-to-250,000-part catalog runs as a scheduled job rather than a multi-year manual effort. The legacy GTM instances stay live and keep filing throughout. The AI Integration service handles the custom connectors so the layer reads from and writes back to systems beyond standard SaaS integrations.

Should I still consolidate onto one GTM platform eventually?

You can, and the data layer makes that decision lower-risk rather than foreclosing it. Once one authoritative record exists, any future migration imports clean, single-sourced data instead of carrying three divergent histories into a new platform, so you decide on consolidation on your own clock. GingerControl's role stays the same whether or not you consolidate: it supplies the classification truth and the integration plumbing through the OpenAPI and AI Integration service, vendor-neutral over whatever stack you run.

Putting one data layer over your legacy GTM stack

If your classification, duty, and origin data are trapped in separate SAP GTS, Oracle GTM, and OneSource instances that never reconcile, you do not have to choose between living with the sprawl and betting a multi-year migration against a live maintenance deadline. GingerControl's AI Integration service and Trade Compliance OpenAPI give you the building blocks to lay one programmatic compliance data layer across the stack, treating each legacy instance as a system of entry and serving one authoritative, audit-ready classification record back to all of them. Augment, don't replace. See how AI Integration unifies the stack →

GingerControl is not just a tool. We work with enterprise trade-compliance teams on process consulting, digital transformation strategy, and end-to-end custom integration across legacy GTM and ERP systems, every engagement starting with a free 30-minute compliance audit. Talk to our team →

References

[REF 1] SAP GTS 11.0 End of Mainstream Maintenance (via Rimini Street) Data cited: SAP ended mainstream maintenance for SAP GTS 11.0 on December 31, 2025; tax, legal, and regulatory updates no longer provided after that date. Source: Rimini Street, SAP End-of-Mainstream-Maintenance Deadlines for GTS, BOBJ, BPC, BW and Hybris Published: 2025

[REF 2] SAP GTS 11 End of Maintenance Migration Guidance Data cited: Post-deadline pathways (extended maintenance, customer-specific maintenance) and migration options including GTS embedded in S/4HANA. Source: SAP Licensing Experts, SAP GTS 11 End of Maintenance Published: 2025

[REF 3] Oracle Support, Premier Support for On-Premises Oracle Transportation Management / Global Trade Management to Cease Data cited: Premier Support for on-premises OTM/GTM ceasing; 6.5.x line as the last on-premises release; Oracle transition toward cloud. Source: Oracle Support Document 2966726.1 Published: Oracle Support knowledge base

[REF 4] Thomson Reuters, ONESOURCE+ Launch Data cited: Thomson Reuters launched ONESOURCE+ on November 5, 2025, as an AI-powered intelligent compliance network spanning tax, trade, legal, and risk. Source: Thomson Reuters press release, ONESOURCE+ launch Published: November 5, 2025

[REF 5] CBP, Reasonable Care Informed Compliance Publication Data cited: Importer-of-record duty under 19 U.S.C. 1484 to use reasonable care to enter, classify, and value merchandise; reasonable care as an operational standard. Source: U.S. Customs and Border Protection, Reasonable Care (Informed Compliance Publication) Published: September 2017 revision

[REF 6] Recordkeeping requirements, 19 CFR Part 163 Data cited: Records relating to an entry must be kept for five years from the date of entry. Source: eCFR, 19 CFR Part 163 (Recordkeeping) Published: current eCFR

[REF 7] CBP Rulings HQ H290535 and HQ H350722 Data cited: Classifying specific goods beyond the 6-digit HS level for importation constitutes customs business under 19 U.S.C. 1641 and requires a licensed customs broker; AI-assisted classification beyond six digits with Form 5106 (HQ H350722, January 16, 2026). Source: CBP CROSS rulings database Published: HQ H290535; HQ H350722 (January 16, 2026)