Most post-go-live ERP incidents are not caused by a misconfigured screen. They come from a broken flow between systems. A validated order in ERP never reaches the WMS. A payment captured in e-commerce never lands in accounting. A stock correction done in a workshop tool never comes back to MRP.
These failures share one pattern: isolated functional tests rarely catch them. They appear in cross-application sequences, often under load, and often on edge cases that nobody replayed before cutover.
This guide gives you a field-tested J-90 to J+7 execution model to secure ERP/API integrations. The goal is not to produce a theoretical quality pack. The goal is to reach go-live with evidence of reliability, clear risk ownership, and a team that can make Go/No-Go decisions based on facts.
Why ERP/API integration testing is still the weak point in many projects
A standard ERP project plan usually covers workshops, configuration, and business testing well. Integration, however, is often treated as a side stream spread across technical tickets between the ERP implementer, data team, e-commerce partner, and sometimes a third-party vendor.
The result is simple: nobody owns the end-to-end view.
- Business teams validate processes inside ERP, but not downstream propagation.
- API teams validate contracts, but not real behavior with messy data.
- Operations monitor jobs, but without business-priority visibility on critical flows.
When these responsibilities are not aligned by J-90, UAT becomes a funnel. Issues arrive late, stack up, and force last-minute trade-offs.
What you must test, exactly
ERP/API integration testing is not a handful of HTTP calls returning 200. You need coverage across four dimensions.
1. Exchange contract integrity
Is the schema respected in both directions? Required fields, data types, date formats, encoding, currency handling, rounding rules, idempotency keys.
A contract can be technically valid and still be operationally wrong if business semantics differ. Classic example: status=confirmed means “commercially approved” in source, while the target system interprets it as “ready to ship”.
2. Step orchestration
Flows must be validated as sequences, not isolated events. A B2B sale can pass through CRM, ERP, WMS, TMS, e-invoicing, and accounting.
The useful question is not “does the API respond?” but “does the full process reach the expected business state with traceability and no manual intervention?“
3. Error robustness
A reliable flow is not one that never fails. It is one that fails cleanly, recovers correctly, and alerts the right people.
Explicitly test:
- Timeouts and retries.
- Duplicate messages.
- Partial payload loss.
- Third-party system unavailability.
- Business failure after technical success (the most dangerous case).
4. Observability and run operations
Without usable logs, integration incidents become a treasure hunt.
Every critical flow must have:
- A cross-system correlation ID.
- A readable business status (not only technical codes).
- Alert routing with thresholds and escalation rules.
- A documented replay and recovery procedure.
The J-90 to J+7 execution plan
The logic is straightforward: as go-live gets closer, uncertainty must decrease. By J+7, the team should not be discovering structural integration behavior for the first time.
J-90 to J-75: define critical flows and Go/No-Go criteria
This is the highest-leverage phase, and often the most neglected.
Expected deliverables
- Critical flow map: order-to-cash, procure-to-pay, inventory, invoicing, reporting.
- Interface register: owner, protocol, frequency, direction, dependencies.
- Criticality matrix: business impact of failure, delay tolerance, fallback options.
- Go-live entry criteria for integrations signed by IT and business.
Decisions to lock early
- Who has authority to call No-Go if a critical flow is unstable?
- What open-defect threshold is acceptable by severity level?
- Which flows are mandatory on day 1, and which can be deferred to post-go-live waves?
If you skip these decisions at J-90, you will revisit them under pressure at J-3.
J-74 to J-60: harden API contracts and test data
A large share of integration defects come from data quality, not code quality.
Priority actions
- Normalize shared master data: customers, items, taxes, units, warehouses.
- Build representative test datasets, including edge conditions.
- Validate field mappings with a business + technical pair.
- Lock idempotency strategy on transactional flows.
Edge datasets people often forget
- Partial returns.
- Credit notes with cross-references.
- Multi-company or multi-warehouse scenarios.
- Atypical VAT/tax cases.
- Cancelled lines later reactivated.
If your tests cover only clean standard cases, production incidents will come from exceptions.
J-59 to J-45: execute contract and baseline integration tests
This phase validates technical consistency at scale.
What must be executed
- Contract tests on producer and consumer sides.
- API version-compatibility tests.
- Mapping tests for each business object.
- Error-handling and return-code tests.
- Duplicate handling and replay tests.
What must be produced
- Execution report with scenario-level status.
- Gap list classified by severity.
- Immediate-fix versus later-wave decision per issue.
Do not let integration defects disappear inside a generic backlog. Isolate and govern them with dedicated ownership.
J-44 to J-30: run end-to-end journeys in realistic conditions
At this point, move from “API-by-API” validation to business process validation.
Scenario examples to replay
- B2B web order with discount, partial picking, shipment, invoicing, payment collection.
- Supplier receipt, quality check, stock update, accounting valuation.
- Customer creation in CRM propagated to ERP and support platform.
- Stock correction and downstream impact on replenishment planning.
Critical acceptance rule
A scenario is “passed” only if:
- Final business state is correct.
- Accounting entries are consistent.
- Intermediate statuses are traceable.
- No hidden manual workaround was needed.
J-29 to J-15: load, resilience, and recovery readiness
Flows must be stress-tested in realistic operating conditions.
Mandatory tests
- Transaction spikes during critical windows.
- Controlled degradation of a third-party service.
- Queue saturation and controlled drain.
- Simulated network interruption and recovery.
- Service restart during active processing.
Evidence you need before go-live
- Platform handles expected throughput.
- Retry mechanisms do not generate business duplicates.
- Alerts reach the correct responders.
- Support teams can replay flows without data corruption.
Without this evidence, you do not have a reliable integration landscape. You have a demo that works in calm conditions.
J-14 to J-7: full cutover rehearsal
A dry-run cutover is non-negotiable.
What a useful dry run includes
- Change freeze according to planned window.
- Data migration execution.
- Flow activation in target sequence.
- Chained validation of critical flows.
- Joint sign-off by business, IT, and run operations.
Expected outputs
- Real timing per step.
- Friction points list.
- Rescheduling decision where required.
- Final cutover runbook version.
A dry run that does not measure real timings does not produce actionable information.
J-6 to J-1: controlled freeze and final Go/No-Go check
This is usually the most politically sensitive period. Schedule pressure rises, and teams are tempted to force a launch.
Discipline rules
- No new scope.
- No last-minute mapping redesign.
- Fix only blocking defects.
- Daily risk review with explicit decisions.
Integration Go/No-Go checklist
Go-live should be approved only if:
- No open blocking defect remains on critical flows.
- Recovery procedures have been tested.
- Hypercare on-call roster is staffed.
- Vendor and partner escalation contacts are confirmed.
Go-live day: run a control room, not fragmented chats
Day-0 coordination must be centralized.
Minimum operating model
- Single war room with a clearly identified decision owner.
- Real-time dashboard for critical flows.
- Timestamped incident log.
- Recurring situation updates with recorded decisions.
Golden rule
When an anomaly occurs, follow the predefined procedure. Do not improvise a production patch before evaluating downstream impact on other flows.
J+1 to J+7: hypercare focused on stabilization
Hypercare is not vague “extra support”. It is a stabilization phase with specific outcomes.
Week-1 objectives
- Reduce open-incident backlog.
- Verify replay quality on failed flows.
- Remove temporary manual workarounds.
- Tune monitoring based on real incidents.
Useful hypercare KPIs
- Critical-flow success rate.
- Mean time to resolution.
- Number of manual replays.
- Number of repeat incidents by root cause.
By J+7, the goal is to transition to normal operations, not to prolong permanent crisis mode.
Recommended RACI to remove gray zones
Most integration crises are not caused by lack of technical skill. They are caused by unclear ownership.
A simple RACI is usually enough:
- Business flow owner: validates expected business outcomes.
- Integration lead: guarantees technical end-to-end behavior.
- Run/operations owner: monitors, alerts, executes recovery procedures.
- ERP project manager: arbitrates priorities and risk governance.
This RACI must exist before final testing, not after first incidents.
The mistakes that cost the most
1. Testing APIs instead of testing processes
An “API OK” status does not mean the process is reliable. Until the full business chain is validated, risk remains high.
2. Underestimating exception scenarios
Standard flows usually pass. Incidents come from returns, cancellations, late corrections, and incomplete data.
3. Mixing structural redesign with go-live urgency
At J-3, fix only what blocks production. Deep redesign introduces new, untested risks.
4. Not documenting replay and recovery
Without a clear replay procedure, every incident depends on one key person. That human bottleneck is avoidable.
5. Running hypercare without business steering
A “technical” incident can have major revenue or customer impact. Hypercare priorities must stay aligned with business priorities.
Operational summary checklist
Before closing preparation, confirm you have:
- Mapped and prioritized critical flows.
- Defined and signed Go/No-Go criteria.
- Built realistic test datasets with edge cases.
- Executed contract and orchestration tests.
- Replayed end-to-end scenarios in target-like conditions.
- Tested load, resilience, and replay procedures.
- Completed at least one full cutover rehearsal.
- Set up a war room and J+7 hypercare model.
If one of these items is missing, it is not a detail. It is an explicit risk to accept or resolve before cutover.
Conclusion
ERP/API integration testing is a delivery discipline, not a technical formality. The J-90 to J+7 method gives you a concrete framework to turn a fuzzy topic into a measurable execution plan. The advantage is not to test more. The advantage is to test what matters, at the right time, with clear ownership.
For deeper planning, review our ERP UAT checklist for go-live success, our CRM-ERP integration architecture guide, and our ERP project failure warning signs.
