The connector is configured. The field mapping looks right. Somebody now has to click Run against your live ERP for the first time.

That is the moment integration projects quietly dread. It is why so many stall a week from the finish line. Nobody wants to be the person who wrote four hundred wrong records into the system finance closes on.

That fear is fixable, and not with courage. Aonflow gives you the connectors and the flow builder; the platforms you are connecting give you somewhere safe to point them. This piece covers using both properly before anything touches production.

The Moment Nobody Wants to Own

Integration projects rarely fail at the build. They fail at the handover between “it works” and “it is live.”

The build is satisfying: you configure a connector, map some fields, and watch a record appear on the other side. What has actually been proven is that one record, on a quiet afternoon, with clean data, moved correctly once.

Production is not that. Production has the customer whose name contains an apostrophe. The order placed at 23:58 on the last day of the month. The SKU somebody renamed in a spreadsheet last March. Four hundred records arriving in the same minute.

The gap between those two situations is where the risk lives:

• Volume — one record proves nothing about four hundred.
• Dirty data — real records carry history, and history is messy.
• Timing — flows behave differently under concurrency than in a demo.
• Failure — nobody tested what happens when the far end returns an error.

What “Breaking Production” Actually Looks Like

The phrase sounds dramatic. The reality is usually mundane, and worth being specific about.

Duplicate records. A flow runs twice, or gets re-run after a partial failure, and now you have two of everything. The most common failure, and the most tedious to unwind.

Bad values written at scale. A mapping error is harmless on one record and expensive on four hundred, especially where postings affect the ledger.

A silent half-run. The flow processed sixty records, hit something unexpected, and stopped. Nobody was watching. The two systems now disagree and nobody knows where the boundary is.

Downstream side effects. The write succeeds, then triggers something you forgot — a notification, a replenishment rule, an approval.

Only the second is really about wrong data. The others are about not knowing what happened, which is why observability matters as much as correctness.

Get a Sandbox on Both Sides

A test against production is not a test. Find out what non-production environment each system offers, because the answer differs by vendor.

NetSuite offers a sandbox account, which Oracle describes as a safe and isolated account where you can develop new processes and applications. Oracle is explicit about the use case: test and train staff on existing integrations “without affecting your production data, so you don’t disrupt your business.” The data in it is a copy of production.

Business Central separates environments by type. Microsoft describes a sandbox as one you can play around with, use as a testbed for development, and delete at will. You can also create one that includes production data. One caveat matters later: Microsoft states that for performance tests “the sandbox isn’t reliable enough for that purpose,” because sandboxes run on a different Azure performance tier.

Shopify offers dev stores, formerly called development stores — testing environments that you own and control, explicitly for development and testing, which cannot process real transactions.

Get both sides before you start. Testing a good sandbox against a live system is half a test, and it is the dangerous half.

What Your Sandbox Will Not Copy

This step surprises people, and skipping it costs a day.

A sandbox refresh is not a perfect clone. NetSuite publishes a list of data that is not copied from production to sandbox. Several entries bear directly on an integration test. Tokens created in your production account are not copied during a refresh. Applications authorized using OAuth 2.0 in production are not copied either. Workflow instances and workflow history logs are not copied.

So expect three things:

• You will re-authenticate. Plan for it rather than treating the first auth failure as a bug.
• Sandbox credentials stay separate. Never let a test flow hold production credentials.
• Automations may be missing. If a workflow fires in production but not in your sandbox, your test is missing a side effect.

Ask the same question of every system in the test: what does the sandbox not carry over, and does that gap matter here?

Build a Test Set From Your Worst Day

Clean test data proves that clean data works, which was never in doubt.

Build the set from real records chosen for how awkward they are — pull them from an actual bad week.

A useful test set includes:

• The long tail of record types — every variant you actually have, not just the common one.
• Ugly strings — apostrophes, accents, ampersands, and names longer than the field allows.
• Boundary values — zero quantities, negative adjustments, your largest ever order.
• Records that should fail — an unmatched code, a missing required field, a duplicate.
• Timing edges — a record dated on a period boundary.

That fourth item is the one people leave out. A set where everything succeeds only tests the happy path, and the happy path is not what breaks.

The Four Passes: Connect, Map, Volume, Fail

Run them in order, because each assumes the previous one passed.

Pass one — connectivity. Authenticate against both sandboxes using the same role and permission set the production flow will use. An administrator token proves nothing about a restricted service account.

Pass two — mapping. Run the full test set, then check results by reading records on the destination side rather than the flow’s own success count. A flow can report success and still write the wrong value. It can be told to write the wrong thing, write it perfectly, and report success, because nothing errored. No amount of monitoring catches that afterwards. The check has to happen here.

Give the pass a measurable exit criterion: records in equals records out, and a spot-check of value totals agrees on both sides. The same criterion applies to pass three.

Pass three — volume. Send a realistic batch and watch for rate limiting, timeouts, and partial completion. Given Microsoft’s caveat above, treat sandbox volume results as functional evidence rather than a capacity measurement.

Pass four — failure. Break things deliberately. Revoke a credential mid-run. Send an unmatched code. Feed a malformed value. You are not testing whether it fails, but whether it fails loudly, cleanly, and recoverably.

Then run the batch again. People skip this one, and it catches the duplicate problem this article opened with. Send the identical set a second time. Check that the destination record count has not moved. Safe replay depends on the flow matching on a key that already exists on the destination, rather than inserting blindly. If re-running doubles your data, you have found a design problem, not a test failure. Confirm with the Aonflow team if you are unsure how your flow behaves on a re-run.

Write down the expected result before each pass. A test without a written expectation tends to pass.

How Aonflow Fits the Test Cycle

Most of the work above happens in the systems you are connecting. Aonflow’s part is the flow itself, and the visibility while you test it.

What that means in practice:

• Set the test flow up against your sandbox, not production. Configure it as a separate connection with its own credentials. Check what each system needs to identify a non-production target. A NetSuite sandbox is a separate account. A Shopify dev store is a separate store you own and control. Business Central lists production and sandbox environments for the tenant.
• Read the execution logs, not the vibes. Dashboards, execution logs, and alerts on flow execution are how you tell a clean pass from a quiet half-run.
• Let AI assist the mapping, then verify it. AI-assisted mapping reduces integration time by more than half. It assists the person mapping. A human still decides what each field means and signs off on the flow, and pass two is where that judgement gets checked.
• Use RBAC deliberately. Role-based access control governs who can work on a flow, and audit trails record activity.

Two things are worth settling directly rather than assuming. Whether and how you move a tested configuration from sandbox to live. And how flow changes are tracked over time. Confirm both with the Aonflow team before planning the cutover around the answer.

This matters more than it sounds. If the move is manual, the thing you ship is not the thing you tested. The rebuilt production flow then needs its own connectivity and mapping re-check before the first narrow run.

On the platform’s own posture while you test: Aonflow offers encryption, role-based access control, and audit trails. Data in transit moves over HTTPS, and HTTP access is available through read-only tokens. For security detail beyond this posture, ask the Aonflow team.

Cutover, Monitoring, and Who Owns the Rollback

Going live is the start of the test, not the end. Shrink the blast radius at every step.

Decide the starting scope. One record type, one location, or one day — small enough that a person can check every record by hand.

Decide the reversal. Before the first production run, write down how you would undo it. If the answer is “we would delete the records manually,” that is still an answer. Know it, and know how long it takes.

Decide the freeze and the sign-off. Agree who is not making changes during the window, on both the flow and the connected systems. A config change on the ERP side disrupts a cutover more often than a change to the flow does. One named person confirms the test passed; one named person watches the first run. They can differ; they cannot be nobody.

Keep the test set afterwards. It becomes your regression suite. Re-run it when a connector is updated, or when either vendor changes an API version. That is the usual reason a flow that worked for a year suddenly stops.

Then watch the first business cycle. Reconcile by hand alongside the flow. Compare record counts on both sides daily. Check that a human is actually reading the failure alerts. Self-healing flows detect and recover flows that begin failing, which absorbs transient errors. But a transient error that keeps recurring is a design problem. Watch the pattern, not the individual run.

Frequently Asked Questions

Can I just test in production carefully?
Sometimes, with a read-only flow. For anything that writes, narrow the scope to a handful of records you can check and reverse by hand. Treat that as a first production pass, not as testing.

Do I need a sandbox for both systems?
Yes, if both will be written to. A sandbox on one side and a live system on the other still puts real data at risk. If one system genuinely has no non-production option, say so in the plan. Then weight pass four more heavily, because failure behavior is the part you could not rehearse.

What is the most commonly skipped test?
Failure. Teams test that the right thing happens. They rarely test what happens when something goes wrong, which is where most production incidents originate.

Conclusion — The Bottom Line

Nobody breaks production on purpose. They break it by treating a successful demo as evidence, and by going live in one step instead of several.

The fix is unglamorous. Get a sandbox on both sides. Learn what it does not copy. Build a test set from your ugliest real records. Test connectivity, mapping, volume and failure, with expectations written down first. Then go live narrow, watch it, and widen.

The same discipline applies whatever you are connecting — whether that is Shopify orders into NetSuite or Shopify into QuickBooks Online.

If you have an integration waiting on somebody’s nerve, replace the nerve with a plan. Explore the connectors at aonflow.com, start for free, or request a walkthrough against your own stack.