Commerce Integration Audit Checklist

Summary

Before any replatform or major system change, you need to know exactly what your existing integrations do, how fragile they are, and what breaks if you touch them. This checklist helps you audit integrations with enough depth to make migration decisions, not just document what exists.

A System Inventory Isn't an Audit

Teams typically inventory integrations by listing system names and data types. That's a catalog, not an audit.

A real audit answers harder questions: Which integrations will block your timeline? Which ones mask business logic that nobody documented? Which vendor relationships have licensing implications you'll discover too late?

The goal isn't a spreadsheet. It's surfacing risk, identifying hidden dependencies, and understanding the actual cost of change.

How to Use This Checklist

Work through each section with the people who actually maintain the systems, not just the stakeholders who approved them. For each integration, capture not just the answer, but the confidence level. "I think it syncs nightly" is different from "Here's the cron job."

Score each integration on three dimensions:

Risk: What's the blast radius if this breaks?
Complexity: How hard is this to replicate or replace?
Clarity: How well is this understood and documented?

Establish What You're Looking At and Who Owns It

What is the canonical name for this integration, and does everyone use it consistently?
Who built it originally, and are they still available?
Who maintains it now, internal team, vendor, or abandoned?
Is there a contract or SLA governing this integration's uptime or support?
When was the last time someone made a meaningful change to it?
Is there any documentation? When was it last updated? Does it match reality?

Map What's Actually Moving Between Systems

Most integration failures happen because teams don't understand the data in motion.

What data objects flow through this integration, in both directions?
Where is the system of record for each data type?
What transformations happen in transit, field mapping, unit conversion, currency, timezone?
Are there filters or business rules that exclude certain records?
What happens to data that fails validation, queued, dropped, or logged?
Is any data enriched, derived, or calculated during transfer?
Are there known data integrity issues that get manually corrected downstream?

Assess How Fragile or Portable the Integration Is

What protocol does this integration use (REST, SOAP, SFTP, EDI, direct DB, proprietary)?
Is it real-time, batch, or event-driven? What's the actual frequency?
Where does the integration logic live, middleware, platform-native, custom code, vendor-managed?
What authentication method is used? Who controls the credentials?
Are there IP whitelists, VPNs, or network dependencies?
What happens when the target system is unavailable, retry, queue, fail silently?
Is there rate limiting on either side? Has it ever been hit?
What monitoring exists? Who gets alerted when it fails?

Find the Logic Hiding in Integrations

This is where audits go shallow. These questions find business rules living in integrations instead of in systems.

Does this integration enforce business rules that aren't enforced elsewhere?
Are there conditional workflows based on data values (e.g., orders over $10K route differently)?
What manual workarounds exist for when this integration doesn't handle a scenario?
Are there known edge cases that require human intervention?
Does this integration handle exceptions from promotions, returns, or partial shipments?
What happens during peak traffic, Black Friday, flash sales, batch processing windows?

Understand What Else Breaks

You can't assess migration risk without mapping dependencies.

What other systems depend on this integration's output?
What upstream systems feed data into this integration?
Are there timing dependencies, must this complete before another process runs?
Does this integration share infrastructure with other critical processes?
If you turned this off tomorrow, who would notice first, and how long would it take?

Surface Constraints That Shape Your Options

Vendor and licensing constraints often matter more than technical complexity.

Is this integration tied to a specific vendor contract or platform license?
Are there API call limits, transaction fees, or usage-based costs?
Does the vendor have a migration path or sunset timeline?
Is there a proprietary connector or adapter that doesn't exist on your target platform?
What's the vendor's track record on breaking changes or deprecation?

Scope the Actual Migration Work

Can this integration be replicated on the target platform with native tooling?
Does a comparable third-party connector exist, and what's its maturity?
What's the estimated effort to rebuild this from scratch?
Can this integration be migrated incrementally, or is it all-or-nothing?
What's the rollback plan if the new version fails post-launch?
Are there compliance or audit requirements that affect how you migrate?

Risk Scoring Framework

For each integration, assign a score from 1–5 on each dimension:

Dimension	1 (Low)	5 (High)
Risk	Limited impact if it breaks	Revenue stops, customers affected
Complexity	Simple, standard patterns	Custom logic, undocumented, tribal knowledge
Clarity	Well-documented, understood	Nobody knows how it works

Multiply the three scores. Anything over 50 needs a dedicated migration workstream. Anything over 100 needs a contingency plan.

Turn Answers Into Decisions

An audit is only useful if it drives action:

Prioritize by risk score. High-risk integrations need detailed migration plans before you commit to timelines.
Identify blockers. Some integrations will constrain your platform choice or timeline. Surface these early.
Flag knowledge gaps. Where confidence is low, schedule deeper technical discovery before scoping.
Map to migration phases. Group integrations by when they can be migrated, before cutover, at cutover, or after.
Assign owners. Every integration needs a named person responsible for its migration.

How DigitalStack Supports Integration Audits

DigitalStack treats integration audits as structured data, not static documents. Each integration gets tracked with its dependencies, risk scores, and migration status, connected to the broader discovery context.

When requirements change or stakeholders raise concerns, you can trace decisions back to what you learned in the audit. When someone asks "can we go live without the ERP integration?", you have a scored, documented answer, not a guess.

Integration findings connect to architecture decisions and migration planning, so nothing gets lost between audit and execution.

Next Step

Start your integration audit in DigitalStack. Capture, score, and act on integration complexity, without losing context as your project evolves.