There's a conversation I have regularly. A business has just signed off budget for a new integration — Shopify into their 3PL, their ERP talking to their finance platform, EDI flowing into their order management system. They're excited. The scope is agreed. The timeline is set.

Then, three weeks in, everything stalls.

Not because the technology doesn't exist. Not because the platforms can't be connected. But because the questions nobody asked at the start are now answering themselves — expensively, at the worst possible moment.

The data is messier than anyone admitted. The ERP owner has just left. The API credentials are locked behind a vendor ticket. There's no one person who can actually sign off on scope decisions.

"The most expensive part of an integration project is usually the conversation that didn't happen before it started."

After working through dozens of integration projects — across eCommerce, wholesale, 3PL, ERP and finance stacks — we built a pre-project checklist that surfaces these problems before they become crises. It covers five areas. It takes about 30 minutes to work through honestly. It has saved clients months.

Here it is in full.

The 5 Areas That Make or Break an Integration

01
Data Quality Q1 – Q4

Bad data is the silent killer of integration projects. You can build the most elegant connector in the world and it will fail immediately if the data flowing through it is inconsistent, incomplete, or misformatted. Most teams underestimate this — because nobody has ever audited the data until the integration breaks on it.

Q1
Do you have a single source of truth for product and SKU data?
Inconsistent SKU data is the number one cause of mapping failures. If product IDs differ between your OMS and your 3PL, orders cannot be matched automatically.
Q2
Is your customer and order data clean and consistently formatted?
Mixed date formats, address structures, and currency codes break automated flows — especially common in businesses that have grown through acquisitions or platform migrations.
Q3
Have you audited your data for duplicates or nulls in key fields?
Null order IDs and duplicate records corrupt downstream systems. Run a data quality check before you start building — not after the integration surfaces the problems.
Q4
Do both systems agree on field names and data types?
'order_id' in one system and 'OrderNumber' in another isn't just a naming issue — it requires a mapping rule that needs documenting, testing, and maintaining.
⚠ Common failure point

Teams often discover mid-project that their "clean" data has been maintained differently across departments for years. A quick data audit before kickoff — even a manual one — saves weeks later.

02
API & Technology Q5 – Q8

The technical readiness questions are ones most teams assume they can answer. In our experience, they often can't — not in the detail that matters. "Yes we have an API" and "yes our API supports the operations this integration needs at the volume we require" are very different answers.

Q5
Does every system you want to connect have a published API or EDI specification?
No published spec means custom connector work. Budget at least double the time and expect surprises. Ask for the documentation before the project starts, not during.
Q6
Are API credentials and sandbox environments available to your team right now?
Waiting on vendor access is one of the most common causes of project delay. Some vendors take 2–4 weeks to provision sandbox access. Get this sorted before kickoff.
Q7
Have you confirmed API rate limits won't block your peak order volume?
Some APIs throttle at 100 calls per minute. If you're processing 5,000 orders per hour at peak, the maths doesn't work. Know your ceiling before you build to it.
Q8
Is there a webhook or event-based option, or only polling?
Polling every 60 seconds versus real-time event triggers changes the architecture, infrastructure cost, and latency of your integration. It needs to be a design decision, not a discovery.
03
ERP Readiness Q9 – Q12

ERP integrations deserve their own category because ERP systems carry complexity that other platforms don't. They're often older, often customised, and often have an internal owner who is the single point of failure for the whole project. If that person leaves during the build, you're in trouble.

Q9
Is your ERP on a supported version with integration modules enabled?
Legacy ERP versions often lack the endpoints modern integrations need. This is a discovery conversation that should happen in week one, not week eight.
Q10
Do you have a named internal ERP champion who can answer mapping questions?
Integration projects without a dedicated ERP owner always stall. Someone needs to be the decision-maker on ERP-side questions. Make it explicit before you start.
Q11
Are your chart of accounts and cost centres finalised?
Finance integrations built on an interim account structure need to be rebuilt when that structure changes. It happens more often than anyone wants to admit.
Q12
Have you documented which ERP fields are mandatory versus optional?
Sending optional fields as blank values can trigger validation errors that kill the entire transaction. Know the ERP's rules before you start mapping against them.
04
Team & Ownership Q13 – Q16

If you only read one section, read this one. The majority of integration projects that go over budget or miss their go-live date do so because of team and ownership failures — not technical ones. A clear owner, clear stakeholder sign-off, and a clear error handling process will save more time than any amount of technical preparation.

Q13
Is there a named project owner with authority to make scope decisions?
No single owner means everyone owns it, which means no one owns it. Scope decisions made by committee during a build project are how timelines double.
Q14
Does your team have bandwidth to support UAT and go-live activities?
Integration go-lives require 3–5 days of ops team availability. If your team is at capacity, either push the timeline or reduce the scope. Don't try to do both simultaneously.
Q15
Have stakeholders across ops, finance and IT signed off on the scope?
Late-stage "can we also add..." requests are the single biggest budget risk in integration work. Get sign-off in writing before the build starts, not after the first demo.
Q16
Is there a process for handling integration errors post go-live?
Every integration fails occasionally. The question isn't whether it will — it's who gets the alert and who fixes it when it does. Define this before go-live, not after the first incident.
05
Process & Scope Q17 – Q20

The process questions are often the most uncomfortable, because they require honest answers about whether the current workflow is actually ready to be automated. Automation doesn't fix a bad process — it accelerates it. If your manual order flow has workarounds baked in, the integration will inherit all of them.

Q17
Have you mapped the current manual process end-to-end before automating it?
Automating a broken process creates a faster broken process. Walk the current workflow before you build the new one. You will always find something that changes the spec.
Q18
Are edge cases documented — returns, partial shipments, cancellations?
Edge cases represent about 20% of order volume but 80% of integration complexity. Handle them in the design phase, not as emergency patches after go-live.
Q19
Do you have a fallback process if the integration goes down?
A documented manual fallback turns a potential 2-hour crisis into a 20-minute managed incident. Document it before go-live, distribute it to the team, and test it at least once.
Q20
Have you defined what "done" looks like — with measurable success criteria?
Without defined success criteria, projects drift. The integration is never formally complete, scope creep accelerates, and nobody can declare victory. Define the finish line before you start running.

How to Score Yourself

Go through each question and count your honest yes answers. Don't score the ones you're planning to fix — score the current state. A yes is only a yes if it's true today.

ScoreWhat it meansRecommended action
18 – 20 Strong foundation across all five areas Proceed. Your project has the foundations it needs.
13 – 17 Some gaps that will create risk mid-project Address the no answers before kickoff. Most can be resolved in 1–2 weeks.
< 13 Significant gaps across multiple areas Stop and plan. Starting now will cost more than fixing the foundations first.
✓ One more thing

A low score isn't a reason to cancel the project. It's a reason to take two weeks and fix the gaps. Every no answer is a solvable problem — the only mistake is discovering them after the build has started.

Free Interactive Tool

Score yourself right now.

We've built the checklist as an interactive tool — answer all 20 questions and get your readiness score instantly, with a breakdown of exactly where your gaps are. No email required.

Take the readiness checklist → Or talk to the team about your specific integration project