---
title: "Integration Evaluation Worksheet: Compare Sync Options"
description: "Compare native connectors, managed two-way sync, and custom integrations using the same object coverage, recovery, ownership, and cost requirements."
canonical: https://www.stacksync.com/blog/integration-evaluation-worksheet
last_modified: 2026-09-15
---

# Integration Evaluation Worksheet: Compare Sync Options

> 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

Compare native connectors, managed two-way sync, and custom integrations using the same object coverage, recovery, ownership, and cost requirements.

Author

Ignacio Malpartida · GTM Engineer

Published

September 15, 2026

Read time

4 min read

DATA ENGINEERING

## Compare evidence against the same workload

An integration evaluation worksheet compares options against a defined business workflow, not a list of vendor features. Document the required objects, write directions, identity rules, latency target, and failure tests. Then ask each native connector, managed platform, or custom implementation to meet the same acceptance criteria.

[Download the evaluation CSV](https://www.stacksync.com/downloads/sync-planning/integration-evaluation-worksheet.csv) or [download the Markdown worksheet](https://www.stacksync.com/downloads/sync-planning/integration-evaluation-worksheet.md). The rows cover 12 requirements and provide separate evidence columns for native, managed, and custom options. Empty cells mean evidence is missing; they do not mean a product fails.

Start with your [field mapping workbook](https://www.stacksync.com/blog/two-way-sync-field-mapping-workbook). If one vendor demonstrates ten simple contact fields while another estimates a multi-subsidiary order flow, the comparison is not meaningful. Fix the scope before comparing effort, price, or performance.

## Match the approach to the job

A native integration is often a sensible starting point when it supports the exact pair, objects, and sync rules you need. A managed sync platform becomes relevant when additional systems, object coverage, or operational requirements exceed that fit. A custom implementation is appropriate when a differentiated workflow justifies owning its code and operations.

![An integration shortlist moves from connector coverage to a controlled test and finally to an operating decision.](https://www.stacksync.com/images/blog-diagrams/sync-evaluation-evidence.webp)

*An integration shortlist moves from connector coverage to a controlled test and finally to an operating decision.*

| Approach | Evidence to request | Work your team still owns |
| --- | --- | --- |
| Native connector | Current object matrix, field rules, filters and error behavior | Configuration, business policies and application administration |
| Managed two-way sync | Your objects and both directions working with a recovery example | Mapping decisions, access approval and business acceptance |
| Custom integration | Working implementation plus repeat-delivery and outage tests | Code, API changes, infrastructure, monitoring and on-call recovery |
| Batch export or ETL | Reliable snapshot or incremental load with acceptable freshness | Refresh scheduling and downstream reporting assumptions |

Keep migration separate from synchronization. A one-time export may satisfy a system replacement, but it does not prove ongoing write-back behavior. Similarly, a warehouse load can be successful without supporting edits from the warehouse to the source application.

## Set pass conditions before watching a demo

Use “Must” for requirements that make the workflow invalid if absent, and “Should” for preferences that can be traded against effort or price. A high total feature score cannot compensate for a missing required object or a recovery process that can create duplicate invoices.

- Coverage: show the actual custom object, field types, and relationship—not only a connector logo.
- Ownership: edit a shared field on both sides and explain the winner.
- Identity: repeat a create after an ambiguous timeout and locate the original record.
- Operations: make one record fail validation, then recover it without disturbing successful records.
- Capacity: show measured lag and catch-up behavior for the expected workload.
- Security: document required permissions, data region, and access to sensitive fields.

![A mandatory requirement without evidence leads to a test or rejection; compare operating tradeoffs only among options that meet the required workflow.](https://www.stacksync.com/images/blog-diagrams-mermaid/sync-evaluation-decision.webp)

*A mandatory requirement without evidence leads to a test or rejection; compare operating tradeoffs only among options that meet the required workflow.*

Write a short evidence note with a date and URL or test output. Separate “documented,” “demonstrated in our test,” and “not verified.” These labels prevent a sales conversation from turning into an unsupported production assumption.

## Compare total ownership cost without invented savings

Ask every provider to price the same normal workload, peak workload, and catch-up event. Include environments, support, extra connectors, implementation, and any relevant task, record, API, or volume charges. For a custom build, include maintenance and incident response as well as initial development.

| Cost item | What to write down |
| --- | --- |
| Implementation | Estimated tasks, owners, dependencies and testing effort |
| Recurring service | Quoted scope, billing unit, included capacity and overage rules |
| Operations | Responder time, monitoring, credential rotation and schema maintenance |
| Growth | Expected peak, additional systems and recovery capacity |
| Exit | Configuration export, identity preservation and migration work |

Use current written quotes instead of unverified percentage-savings claims. A lower service fee can be outweighed by a custom recovery process; a broader platform can be unnecessary for a small, stable workflow. Record the tradeoff in terms of your workload and your team’s operating capacity.

Two systems, one record, no batch window

See your own stack synced live. Book a demo with the engineers who built it.

[Book a demo](https://www.stacksync.com/book-a-demo)

## Finish with an acceptance decision

Shortlist only options that meet the mandatory requirements or have a concrete, owned plan to close the gap. Run the [production-readiness checklist](https://www.stacksync.com/blog/two-way-sync-production-readiness-checklist) on the finalist. Record why it was chosen, which limitations were accepted, and which future changes would trigger a reevaluation.

For example, the [native HubSpot–Salesforce integration documents two-way field rules](https://knowledge.hubspot.com/salesforce/map-hubspot-properties-to-salesforce-fields). Its existence means “needs bidirectional sync” alone is not a reason to reject it. Evaluate the actual mapping and operating requirements before selecting an alternative.

If Stacksync fits your shortlist, [request a proof of concept using this worksheet](https://www.stacksync.com/book-a-demo). Bring the selected pair, critical objects, expected volumes, latency target, and hardest recovery case. The useful output is evidence against your requirements, not a generic product tour.

Start with one sync and see it hold

Connect two systems, watch a record move both ways, then decide.

[Start syncing](https://app.stacksync.com/)

FAQ

## Frequently asked questions

How do I compare integration platforms fairly?

Give each option the same systems, objects, mapping rules, workload, and acceptance tests. Record verified evidence and total operating cost, including the work your team must own.

Does a two-way requirement rule out a native connector?

No. Some native connectors support bidirectional fields. Verify their object coverage, write rules, filtering, and operational behavior against your actual requirements.

Should I choose the tool with the most connectors?

Only required systems and likely near-term additions belong in the decision. Correct object behavior and recoverability usually matter more than an unrelated connector count.

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 Two-Way Sync Field Mapping Workbook 6 min read read](https://www.stacksync.com/blog/two-way-sync-field-mapping-workbook)

[Data engineering Two-Way Sync Error Handling: Retries and Replay 8 min read read](https://www.stacksync.com/blog/two-way-sync-error-handling-retries-replay)

[Data engineering Two-Way Sync Production-Readiness Checklist 6 min read read](https://www.stacksync.com/blog/two-way-sync-production-readiness-checklist)

## 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/)