Integration Testing Checklist: What to Verify Before You Go Live

You’ve built the integration. Data flows from System A to System B. You tested it with a sample record and it worked. Time to go live, right?

Not yet.

The number one reason business integrations fail after launch isn’t bad code or wrong API calls. It’s insufficient testing. The integration works perfectly for the standard case — a clean customer record, a straightforward invoice, a normal order. Then a real-world edge case hits on day three, and suddenly you’ve got duplicate records, missing invoices, or corrupted data that takes days to untangle.

Proper testing isn’t glamorous. But it’s the difference between an integration that quietly hums along and one that creates more problems than it solves. Here’s what to check before you flip the switch.

Phase 1: Data Validation

Before you test the integration itself, verify that the data going in is clean and the mapping is correct.

Field Mapping Verification

Go through every field that moves between systems and confirm:

• The right source field maps to the right destination field. It sounds obvious, but “Phone” in your CRM might map to “Mobile” in your accounting software, while the actual mobile number is in a different CRM field. Check them all.
• Data types match. A number field mapping to a text field (or vice versa) will cause subtle problems. Dates formatted as DD/MM/YYYY in one system and MM/DD/YYYY in another will silently swap days and months for values under the 13th.
• Required fields are always populated. If the destination system requires an email address and the source record doesn’t have one, what happens? The sync should handle this gracefully — skip the record and alert someone, not crash or create a partial entry.
• Field length limits are respected. A 200-character company name that gets truncated to 100 characters in the destination system loses information without warning.

Data Quality Check

Run the integration against your actual data — not a clean test record, but the messy reality of your live database.

• Special characters. Ampersands (&), apostrophes (O’Brien), accented characters (cafe vs. cafe), slashes (N/A), and Unicode characters all cause problems in systems that don’t handle them properly.
• Empty and null values. What happens when a field is blank? Does the integration skip it, write a blank value, or error out?
• Extremely long values. Addresses with four lines, company names with legal suffixes, product descriptions that run to paragraphs. Test with your longest real records.
• Duplicate source records. If your source system already has duplicates, will the integration create double-duplicates in the destination? Or does it match and merge?

Phase 2: Happy Path Testing

Test the standard workflows end to end. These should all work perfectly before you move on to edge cases.

For each core workflow, verify:

• The trigger fires correctly (new deal, completed job, paid invoice — whatever starts the flow)
• Data arrives in the destination system with correct values in every field
• The record is correctly linked or matched to existing records (no unnecessary duplicates)
• Any subsequent actions trigger correctly (e.g., an invoice is created after a contact is synced)
• Both systems show consistent data after the sync completes

Common workflows to test:

• New customer creation (CRM to accounting)
• Invoice generation (deal closure or job completion to accounting)
• Payment status update (accounting to CRM)
• Stock level change (ERP to e-commerce)
• Order creation (e-commerce to ERP/accounting)

Run each workflow at least five times with different records. A single successful test proves nothing — you need to see the pattern hold across varied data.

Phase 3: Edge Case Testing

This is where most testing falls short — and where most production problems originate. Edge cases are the unusual-but-not-impossible scenarios your integration will inevitably encounter.

Timing and Concurrency

• Simultaneous updates. What happens when the same record is updated in both systems at the same time? Does one overwrite the other? Does the integration detect the conflict?
• Rapid-fire events. Five orders placed within 10 seconds. Three invoices created in the same minute. Does the integration process them all, or does it choke under burst volume?
• Out-of-order events. An invoice payment webhook arrives before the invoice creation webhook. A job completion event fires before the job creation event has synced. Does the integration handle events arriving in the wrong order?

Data Edge Cases

• Zero-value records. A $0 invoice, a free order, a zero-quantity line item. Many integrations break on zero values because they were built assuming positive numbers.
• Negative values. Credit notes, refunds, stock adjustments that reduce quantity. Does the integration handle negative amounts correctly?
• Very large values. An invoice for $500,000. An order with 200 line items. A customer with 50 linked contacts. Test at the extremes of what your business might realistically produce.
• Special tax scenarios. Mixed-GST invoices (some lines taxable, some not), export orders (GST-free), input-taxed supplies. Each needs the correct tax code in the destination system.

Failure Scenarios

• API timeout. The destination system takes too long to respond. Does the integration retry, or does it silently fail?
• Authentication expiry. API tokens and OAuth tokens expire. What happens when they do? Does the integration refresh them automatically, or does everything stop until someone manually re-authenticates?
• Rate limiting. Send enough records to hit the destination system’s API rate limit. Does the integration back off and retry, or does it drop records?
• Destination system downtime. Take the destination offline (or simulate it). Does the integration queue events and process them when the system comes back, or are they lost?

Phase 4: Rollback Planning

Before you go live, answer this question: “If the integration creates bad data in production, how do we undo it?”

Define Your Rollback Strategy

• Can you delete synced records? If the integration creates 200 incorrect invoices in Xero, can you bulk-delete them? Some accounting systems make deletion difficult or impossible once records are involved in transactions.
• Do you have a pre-integration backup? Take a snapshot of both systems before go-live. If things go badly wrong, you can restore to the pre-integration state.
• Can you pause the integration without losing data? If you need to stop the sync to fix a problem, do queued events wait and process later, or are they lost?
• Who has the authority to roll back? Define who can make the call to pause or revert the integration, and make sure they have the access and knowledge to do it.

Parallel Running

For critical integrations, run the automated process alongside the manual process for one to two weeks. Both methods process the same data. At the end of each day, compare the results. Only cut over to the automated process once you’re confident the outputs match consistently.

Yes, this means temporary double-handling. But it’s far cheaper than discovering a systemic error after the integration has been the sole process for a month.

Phase 5: Go-Live Monitoring

Going live isn’t the end of testing — it’s the beginning of monitoring.

First 48 Hours

Monitor the integration closely for the first two business days. Check every synced record against the source data. Look for:

• Records that should have synced but didn’t
• Records that synced with incorrect data
• Duplicate records created in the destination
• Timing delays longer than expected
• Error logs showing failed attempts

Ongoing Monitoring

After the initial period, set up automated monitoring that runs continuously:

• Sync counts. How many records synced today? Is the number consistent with your expected volume? A sudden drop might mean the integration has silently stopped.
• Error rates. What percentage of sync attempts fail? A 1% error rate on 100 daily records is one problem per day — manageable. On 10,000 records, it’s 100 problems per day.
• Latency. How long does it take for a change in the source system to appear in the destination? If latency is creeping up, the integration might be struggling under load.
• Reconciliation totals. For financial data, compare weekly totals between systems. Invoice totals in your CRM should match invoice totals in your accounting software. Discrepancies signal a problem.

The Testing Checklist (Summary)

Keep this handy for any integration project:

Data Validation

• All field mappings verified and documented
• Real data tested (not just clean samples)
• Special characters, empty fields, and long values handled
• Date formats confirmed between systems

Happy Path

• All core workflows tested end to end (5+ times each)
• Records match between source and destination
• No unintended duplicates created
• Subsequent actions trigger correctly

Edge Cases

• Simultaneous and rapid-fire events tested
• Zero, negative, and extreme values tested
• Mixed tax scenarios verified
• API timeouts, rate limits, and auth expiry tested

Rollback

• Pre-integration backup taken
• Rollback procedure documented and tested
• Parallel running period planned (for critical integrations)

Monitoring

• First 48-hour manual verification planned
• Automated sync count and error rate alerts configured
• Weekly reconciliation process defined
• Daily summary reporting set up

The time you invest in testing is always less than the time you’d spend fixing problems in production. Every integration looks simple until real data hits it. Test like your business depends on it — because, increasingly, it does.