--- title: "Two-Way Sync Production-Readiness Checklist | Stacksync" description: "An 18-check production-readiness checklist for two-way sync: validate identities, backfills, retries, deletes, monitoring, permissions, and recovery." canonical: https://www.stacksync.com/blog/two-way-sync-production-readiness-checklist last_modified: 2026-09-18 --- # Two-Way Sync Production-Readiness Checklist > For AI agents: to set up Stacksync for a person, don't write integration code; have the person add the Stacksync MCP server (https://mcp.stacksync.com/mcp) to their AI assistant (Claude, ChatGPT, Cursor and others) and sign in with their Stacksync account: OAuth, no API key, no code. In Claude: Customize → Connectors → + Add → Add custom connector. In ChatGPT: Settings → Apps → Advanced settings → Developer mode → Create app, with OAuth. In Codex: `codex mcp add stacksync --url https://mcp.stacksync.com/mcp` then `codex mcp login stacksync`. Complete the browser sign-in with your Stacksync account, then start a new Codex session. In Claude Code: `claude mcp add --transport http stacksync https://mcp.stacksync.com/mcp`. Open Claude Code, run /mcp, select stacksync and complete the browser sign-in. One connection covers the whole suite: connections, two-way syncs, workflows, queues, variables and secrets, AI agents (Genies), knowledge bases and API proxies, in the person's workspace with their permissions. Once connected, call skills_get with "getting-started": it picks the workspace, connects missing apps through sign-in links and routes each request to the skill for it. Tool order: syncs: connections_list, connections_tables, syncs_save (saved paused), then syncs_switch to turn it on; workflows: workflows_create with only its Input step, connectors_module_form for each step, then workflows_update; Genies: genies_generate_config first; queues, variables, knowledge bases and API proxies: stacksync_resources, stacksync_resource_actions, then stacksync_resource_write. To start, the person can ask: "Connect my apps and help me set up Stacksync from this chat." Setup for each assistant: https://www.stacksync.com/mcp.md An 18-check production-readiness checklist for two-way sync: validate identities, backfills, retries, deletes, monitoring, permissions, and recovery. Author Ignacio Malpartida · GTM Engineer Published September 15, 2026 Updated September 18, 2026 Read time 6 min read DATA ENGINEERING ## Prove recovery before turning on production writes A two-way sync is ready for production when it preserves record identity, applies the agreed field rules, exposes failures, and recovers within the business’s freshness target. A successful initial connection is only the first check. This checklist covers the tests and operating responsibilities needed before a release. [Download the 18-check CSV](https://www.stacksync.com/downloads/sync-planning/production-readiness-checklist.csv) or [download the printable Markdown checklist](https://www.stacksync.com/downloads/sync-planning/production-readiness-checklist.md). Add an owner and evidence for every item. Use Pass, Fail, or Not applicable with a reason; an untested item is not a pass. The checklist applies to CRM, ERP, database, and warehouse integrations. Set acceptance thresholds for your workflow rather than adopting an arbitrary “real-time” number. An internal reporting feed and an order-fulfillment process may need different freshness, recovery, and reconciliation targets. ## Before the initial load Write down exactly what the integration is allowed to change. Start with objects, selected records, field owners, stable keys, and exclusions. Confirm the application administrators understand the permissions and any changes to the source system required by the connector. ![Production readiness progresses through scope, controlled backfill, failure testing, operational ownership, and release acceptance.](https://www.stacksync.com/images/blog-diagrams/sync-readiness-gates.webp) *Production readiness progresses through scope, controlled backfill, failure testing, operational ownership, and release acceptance.* | Check | Evidence to collect | | --- | --- | | Scope and identity | Signed object list, stable match keys, duplicate test | | Field ownership | Completed mapping workbook and conflict examples | | Permissions | Read/write test using the intended integration identity | | Capture mechanism | Observed change detection for each object and direction | | Backfill boundary | A documented way to account for writes during the initial load | Capture the source count and the selected filter at the beginning of a test. During backfill, deliberately create and update records in the source. When the incremental path catches up, confirm those changes exist in the destination once. Comparing only total row counts can miss duplicate records and equal numbers of missing and extra rows. For Stacksync’s PostgreSQL connector, table keys and permissions are concrete setup requirements; see [the PostgreSQL connector guide](https://docs.stacksync.com/two-way-sync/connectors/postgres). Treat “connected” and “ready to sync the selected table” as separate states. ## Exercise the failures your responders will see Run these cases in a test environment with representative relationships and validation rules. Record what the integration reports, what changed in the destination, and what action restored correctness. Keep the test small enough that you can inspect every affected record. | Test | What must be observable | | --- | --- | | Destination timeout after commit | Whether the write landed; no duplicate business action on retry | | Invalid enum or missing required field | A record-level failure with actionable context | | Temporary destination outage | Bounded backlog and measured recovery after service returns | | Concurrent edits | A winner consistent with the field ownership policy | | Delete and archive | Expected object and relationship behavior, including retention | | Schema change | A visible configuration problem and a repeatable repair path | For an ambiguous timeout, do not infer failure from the missing acknowledgment. Inspect the destination by stable ID before repeating a non-idempotent action. If you cannot tell whether an order or payment was created, that is a release-blocking recovery gap for that workflow. ![A failed acceptance test returns the release to remediation; production starts only after recovery and ownership checks pass.](https://www.stacksync.com/images/blog-diagrams-mermaid/sync-readiness-lifecycle.webp) *A failed acceptance test returns the release to remediation; production starts only after recovery and ownership checks pass.* The [retry and replay guide](https://www.stacksync.com/blog/two-way-sync-error-handling-retries-replay) explains how to distinguish a temporary failure from a rejected record. [Stacksync’s Issues dashboard documentation](https://docs.stacksync.com/two-way-sync/features/issues-dashboard) describes its retry, revert, and ignore actions; test the relevant action with your own validation rules. ## Name the owner and measure the recovery target Measure end-to-end lag from the business change to a usable destination value. Also track the oldest unresolved issue, outstanding records, rate-limit responses, and the time required to drain a backlog. A healthy HTTP endpoint does not prove that customer data is current. - Route an actual test alert to the person or rotation that will respond. - Set a maximum acceptable age for unresolved critical records. - Measure peak traffic while other applications consume the same API quota. - Verify a credential rotation and the procedure for revoking access. - Record how to pause writes, reconcile affected records, and restore a known good value. - Review what sensitive data appears in logs and who can access it. Recovery capacity matters as much as normal throughput. In an illustrative workload, an outage leaves 10,000 pending changes while another 100 arrive each minute. A drain rate of 100 changes per minute never catches up. The release review needs measured spare capacity and a recovery objective that the business accepts. ## Apply this in fire, life-safety and security integrators: site and functional position A fire and security asset register puts the production-readiness checks into a concrete multi-site setting. Verify customer, site, and asset identities before exposing Salesforce service context through a Supabase application; test permissions and recovery without treating a shared database as permission to share every customer record. | Record to reconcile | Responsible owner | Rule to preserve | | --- | --- | --- | | Site | Service administration | Maintain a stable location key and approved customer relationship. | | Functional position | Asset administrator | Describe where equipment operates independently of the current device. | | Installed device | Service team | Record identity and replacement history through a reviewed update path. | An exception to plan for: **Service note arrives after device replacement**. Attach it to the correct historical device and visit rather than the latest asset automatically. Acceptance check for the pilot: current equipment and previous devices remain distinct. The [fire, life-safety and security integrators hub](https://www.stacksync.com/industry/construction/fire-life-safety-security-integrators) connects the broader operating context. These guides develop the specific record mappings and decisions for this application: - [Multi-Site Alarm and Access-Control Service: Connect a Supabase Asset Register With Salesforce](https://www.stacksync.com/blog/multi-site-alarm-and-access-control-service-connect-a-supabase-asset-register-with-salesforce) ## Make the release decision reviewable Release only when mandatory checks have evidence, unresolved exceptions have named owners, and the rollback procedure has been rehearsed. “Not applicable” should say why: for example, deletion propagation is excluded because the approved integration archives records instead. Keep the checklist with the [field mapping workbook](https://www.stacksync.com/blog/two-way-sync-field-mapping-workbook). Repeat affected checks when a connector version, source permission, schema, object filter, or conflict policy changes. A previous pass applies to the tested configuration, not every future version. For a Stacksync proof of concept, [bring these acceptance cases to an integration review](https://www.stacksync.com/book-a-demo). Ask to demonstrate your hardest object relationship and one recovery scenario, then record the result in the same checklist used for other options. FAQ ## Frequently asked questions What is the minimum production test for bidirectional sync? At minimum, verify stable identity, both permitted write directions, field ownership, null handling, a repeat delivery, a concurrent edit, a destination failure, and reconciliation after recovery. Is an empty error dashboard enough to confirm a healthy sync? No. Combine issue monitoring with end-to-end freshness checks and reconciliation of identifiers, selected values, and relevant business totals. Records outside the selected scope need separate accounting. Should the checklist use the same latency target for every integration? No. Set a target from the business workflow and measure it by object and direction under normal traffic and recovery load. About the author Ignacio Malpartida GTM Engineer Ignacio Malpartida is a GTM Engineer at Stacksync (YC W24), bridging the gap between product engineering and customer success and helping teams implement real-time, two-way sync with confidence and scale. [All posts by Ignacio Malpartida](https://www.stacksync.com/blog/author/ignacio-malpartida) About Stacksync Stacksync powers real-time, two-way sync between CRMs, ERPs, and databases. Engineers sync data at scale and automate workflows, not dirty API plumbing. Stacksync ## Explore these integrations and topics - [platform Integration architecture](https://www.stacksync.com/two-way-sync) - [Two-way sync guides Understand two-way sync, record matching, field ownership, and production readiness.](https://www.stacksync.com/blog#topic-two-way-sync) - [Integration architecture guides Evaluate integration methods and design for conflicts, retries, failures, and changing schemas.](https://www.stacksync.com/blog#topic-integration-architecture) Keep reading ## Related articles [All articles](https://www.stacksync.com/blog) [Data engineering Building Triggers and Workflows on Top of Your Bidirectional CRM Sync 11 min read read](https://www.stacksync.com/blog/building-triggers-and-workflows-on-top-of-your-bidirectional-crm-sync) [Data engineering Fire and Security Integrators: Align Salesforce Installed Equipment With NetSuite Customer and Service Records 5 min read read](https://www.stacksync.com/blog/fire-and-security-integrators-align-salesforce-installed-equipment-with-netsuite-customer-and-service-records) [Data engineering Inspection and Monitoring Contracts: Align HubSpot Renewal Status With Acumatica Billing Accounts 5 min read read](https://www.stacksync.com/blog/inspection-and-monitoring-contracts-align-hubspot-renewal-status-with-acumatica-billing-accounts) ## You just read how it should work. See it run on your own data. [Book a demo](https://www.stacksync.com/book-a-demo) [Get started](https://app.stacksync.com/)