Systems integration ERP APIs work until the first major upgrade—then undocumented glue, fragile file drops, and “temporary” scripts become the critical path. Singapore and Philippines mid-market estates that survive ERP upgrades treat integration as a product with owners, versioned contracts, and strangler facades—not as leftover project work. This article focuses on upgrade survival and ownership, complementing WC1’s broader API-first integration patterns for ERP, CRM, and HIS landscapes.
Systems integration ERP APIs: design for the upgrade you will actually do
Every ERP programme promises clean APIs; every brownfield estate accumulates point-to-point exceptions. Upgrades—version jumps, cloud migrations, module replacements—break implicit contracts: field meanings change, auth models shift, batch windows move, and custom Z-transactions disappear. Teams that only tested happy-path sync discover the breakage in production cutover weekends.
Survive by making three decisions early: who owns the glue, how contracts are versioned, and where strangler facades sit so cores can move while edges stay stable. APAC multi-entity rollouts add country packs and shared-services traffic; upgrade risk is organisational as much as technical.
Inventory before architecture theatre. List every inbound and outbound interface with volume, criticality, owner, and last successful replay test. Many “unknown” jobs surface only when someone disables a server. That inventory is the upgrade programme’s real scope statement for integration.
1. Ownership of glue code is non-negotiable
If “integration” is everyone’s side task, it is nobody’s product. Name an owning team (platform, integration, or a clearly mandated vendor pod) with a backlog, runbooks, and on-call expectations. Store glue in repositories you control—even when a SI builds it. Build pipelines, secrets management, and observability belong to the owner, not to a departing project folder.
- RACI for each interface: business owner, technical owner, ERP basis/admin, consumer apps.
- Source of truth for mappings (customer, item, tax, chart of accounts) with change control.
- SLOs for lag, error rate, and poison-message handling—not only “job succeeded.”
- Documented restart and replay procedures that non-heroes can execute.
- Acceptance tests that block “done” without repo and runbook handover.
Commercial models matter: staff-aug that leaves undocumented scripts is a future outage. Prefer delivery models where knowledge transfer and repo hygiene are acceptance criteria. For longer-lived capacity, dedicated team constructs such as ODC dedicated teams can hold integration ownership across upgrade seasons—if governance is real.
2. Versioned APIs and explicit contracts
Prefer versioned APIs, events, or well-described file schemas over reading ERP tables directly. Consumer teams should depend on a contract: payload shape, idempotency keys, error semantics, and deprecation windows. When the ERP upgrades, the facade can adapt while consumers migrate on a schedule.
Avoid silent field reuse. If “status code 4” changes meaning between ERP versions, that is a breaking change—even if the column name stayed. Contract tests in CI beat wiki pages that drift. For high-volume APAC shared services, include multi-entity identifiers in the contract so Philippines processing centres do not infer entity from folder names.
Idempotency deserves explicit design. Upgrades produce retries. If posting an invoice twice creates duplicate financials, you do not have an integration—you have a reconciliation factory. Bake idempotency keys and natural business keys into contracts before cutover week.
3. Strangler facades around upgrade blast radius
A strangler facade sits between consumers and the ERP (or legacy) so you can replace routes gradually. During upgrades, keep the facade’s external contract stable while swapping internal adapters—old RFC/BAPI/table reads to new APIs, or on-prem endpoints to cloud equivalents. This mirrors broader legacy modernisation practice described in legacy modernization without the big bang.
Facades are not another junk drawer. Limit scope per domain (orders, master data, finance postings). Give each facade a clear owner and deprecation plan for bypasses. Temporary direct connections have a nasty way of becoming permanent during cutover stress—track them as risk debt with expiry dates.
4. Cutover and dual-run discipline
Upgrade weekends fail when integration dual-run is improvised. Plan: parallel read validation, controlled write switch, reconciliation reports, and abort criteria. Rehearse with production-like volumes, including the ugly interfaces nobody wants to demo. Freeze mapping changes before cutover unless emergency-controlled.
Data migration and integration are cousins; do not staff them as strangers. Master data cleanse unfinished before upgrade becomes endless exception fuel for IDP and AP automation downstream. Shared services leaders in the Philippines should sit in cutover rehearsals when their queues depend on the interfaces—surprises at Monday open are expensive.
5. Observability and poison messages
Log correlation IDs across ERP, middleware, and consumers. Dead-letter queues need playbooks: who retries, who amends master data, who accepts business exception. Dashboards that only show “messages sent” hide the backlog that shared services feel as “ERP is slow.”
Security upgrades travel with ERP upgrades: OAuth shifts, certificate rotations, IP allowlists for hybrid links. Put those in the upgrade checklist beside functional tests—hybrid estates in Singapore/Philippines hubs are especially sensitive to broken private links after network changes.
Practical anti-patterns
- Reading core tables because “API was incomplete” and never revisiting.
- Storing secrets in job schedulers under a shared ops login.
- One mega-interface that mixes master data, transactions, and analytics extracts.
- Vendor-owned black-box glue with no repo access at exit.
- Skipping consumer contract tests because “the SI will handle cutover.”
- Treating file drops on a shared drive as an integration strategy without checksums or late-file handling.
When Singapore HQ owns the ERP programme and Philippines shared services consume the interfaces, governance must span both. Upgrade steering should include a standing integration workstream with authority to freeze risky bypasses—not only a technical checklist owned by the SI. Country packs, tax engines, and bank files deserve explicit regression suites because they break quietly and hurt cash and compliance first.
Build a consumer compatibility matrix before upgrade. List each downstream system—CRM, WMS, payroll, shared-services bots, IDP postings—and the contract version it depends on. Schedule consumer migrations explicitly; “they will adapt” is not a plan. Shared services cutover playbooks should include who validates the first one hundred transactions in each critical queue.
Treat bank files, e-invoicing, and statutory extracts as first-class interfaces. They are often owned by finance consultants outside the SI’s happy path and fail after ERP version changes. Include them in rehearsal weekends with the same seriousness as order-to-cash APIs.
After go-live, run a 30/60/90-day integration hypercare with clear exit criteria: error budgets met, poison queues stable, and no unmanaged bypasses remaining. Hypercare without exit criteria becomes permanent shadow operations. Capture lessons into the interface catalogue so the next upgrade starts smarter.
How WC1 helps teams keep integrations upgrade-safe
WC1 Entreventures designs integration planes with clear ownership, versioned contracts, and strangler paths so ERP upgrades do not strand the business. We avoid invented uptime claims; we focus on operable glue and acceptance evidence. Conversation starters often sit alongside custom software in the Philippines delivery when build capacity must stay close to shared-services operations.
If systems integration ERP APIs are on your upgrade critical path, contact WC1 to map owners, facades, and the minimum contract tests before the next cutover window.
Cost the upgrade integration workstream honestly. Underfunded interface remediation shows up as emergency change requests after go-live. A modest investment in contract tests and dual-run tooling is cheaper than weeks of shared-services overtime and manual journals. Finance sponsors understand that framing better than abstract “API excellence” slides.
FAQ: integrations that survive ERP upgrades
Should we pause all projects during an ERP upgrade?
Pause mapping changes and new direct couplings; keep facade-level work that reduces cutover risk. A total freeze without a risk backlog often creates shadow workarounds.
Are iPaaS tools enough?
Tools help; ownership and contracts decide outcomes. An iPaaS full of undocumented flows fails upgrades the same way custom scripts do.
How early should integration join the upgrade programme?
At programme charter—not two weeks before cutover. Interface inventory and contract tests need calendar space.
What is the first artefact to demand from an SI?
An interface catalogue with owners, contracts, volumes, and replay runbooks in your repositories—before more feature demos.
How do we know a facade is earning its keep?
Consumers can upgrade on a different cadence than the ERP, contract tests catch breaks before cutover, and dual-run reconciliation stays explainable. If every change still requires hero weekends, the facade is incomplete.
Own the glue, version the contracts, strangle the blast radius—then ERP upgrades become managed change instead of archaeological emergencies.