Quick project snapshot

• Which of these triggers best describes why your team is evaluating an integration platform today? Options: New SaaS go-live requiring connections to 3+ systems, Critical integration failure after a vendor API change, IT audit showing 100+ unmanaged point-to-point integrations, Planned modernization of integration architecture, Other
• Which system categories must be connected in the initial phase? Options: CRM, ERP / financial system, HRIS / payroll, E-commerce / storefront, ITSM / service desk, Data warehouse / analytics, On-prem database, Custom application
• How many distinct integration endpoints do you expect the platform to support in the first 90 days? Options: 1-3, 4-9, 10-25, 26-100, 100+
• Describe the single business outcome that would make this project a clear success for your team

Where current integrations most often break

• When a critical connector fails in production, how many hours does it typically take your team to detect, diagnose, and restore service? Options: Under 1 hour, 1-4 hours, 4-12 hours, 12-48 hours, More than 48 hours
• Which of these failure modes cause the biggest business impact for you? Options: Data loss or duplication, Incorrect field mappings, Silent failures with no alerts, Throughput bottlenecks under peak load, Security or auth failures, Other
• How often do integration incidents lead to measurable business effects such as lost orders, delayed payroll, or missed SLAs? Options: Multiple times per week, Monthly, Quarterly, Rarely, Never
• Which single integration failure would make you stop the project immediately if it could not be prevented or fixed? Options: Persistent data corruption across systems, Inability to meet peak transaction throughput, No transparent error logs or tracing, Security review failure, Other
• Tell us about the last significant outage, what caused it, and what downstream processes were affected

Who holds the invisible knowledge

• Who on your team is the primary owner of undocumented integration logic today, and how reachable are they for handover? Options: Embedded app developer (single person), Integration specialist on ops team, Vendor/third-party consultant, Multiple people share knowledge, No clear owner
• Describe any integrations that must be reverse-engineered because documentation or source code is missing
• How long would it take another engineer to understand and maintain those integration flows if the owner left tomorrow? Options: Under 1 week, 1-4 weeks, 1-3 months, 3+ months, Impossible without vendor help
• If your primary knowledge holder became unavailable during the pilot, would that block the engagement? Options: Yes, immediate block, It would cause delay but not stop, No, we have redundancy, Not sure
• Who must endorse a knowledge-transfer plan before you commit to a vendor-managed migration? Options: VP of IT / CIO, Director of Enterprise Architecture, Lead Integration Developer, Security / Compliance, Procurement, Other

What a pilot must prove to be trusted

• If a pilot demonstrated connector uptime but not accurate transformations against your sample dataset, would you consider it a win? Options: Yes, if we see clear improvement plan, No, transformation accuracy is required, Depends on which connectors fail, Unsure
• Which acceptance criteria are non-negotiable for your pilot (select top three)? Options: Transformation and field-mapping accuracy on representative records, Transparent error logs with stack traces, Sustained throughput at expected peak TPS, Automated retry and dead-letter handling, Security and auth meeting corporate standards, Manageable cost projection
• How many representative records or transactions will you provide for validation during the proof, and in what format? Options: <1,000 records (CSV/JSON), 1,000–10,000 records (CSV/JSON), 10k–100k records (CSV/JSON), Representative streaming events, not a static sample, Other
• Who in your organization has final authority to approve moving from pilot to paid deployment if acceptance criteria are met? Options: VP of IT / CIO, Director of Enterprise Architecture, Head of IT Operations, Procurement with executive sign-off, Other
• List the KPIs you will monitor during the pilot that must move in the right direction to justify expansion

Known roadblocks that stall projects

• Which single internal constraint would prevent the project from starting on the planned schedule? Options: No API credentials or access to key systems, Security or compliance sign-off pending, No dedicated integration resource available, Budget not approved, Other
• Which compliance or legal approvals could add the longest delay to your timeline? Options: Data residency / cross-border transfer, Industry-specific compliance (HIPAA, PCI, etc.), Vendor contractual review, Internal security architecture review, None applicable
• How mature is your API inventory for the systems in scope, in terms of stable endpoints and documentation? Options: Well documented with stable endpoints, Partially documented, some endpoints unstable, APIs exist but are private and need enablement, APIs missing, require custom development
• Estimate the percentage of data that is currently clean and ready for mapping without manual transformation Options: >90%, 70–90%, 40–69%, 20–39%, <20%
• Who would block the project if their concerns were not addressed (name the role and the top concern)

Choices on your table right now

• Which alternatives are you actively evaluating in parallel to a commercial integration platform? Options: Staying with an incumbent vendor, Building internal middleware or scripts, Open-source integration tools, Point-to-point custom integrations, Another commercial integration platform, No alternative being evaluated
• What would have to be true about your current approach for you to keep it instead of changing to a platform? Options: Lower total cost than platform, Meets throughput and reliability needs, No additional headcount required, Vendor commitment to maintain custom work, Other
• Has anyone proposed solving this fully in-house instead of using a vendor, and who is the primary advocate for that option? Options: Yes, architecture/engineering team, Yes, application owners, No internal build proposal, Not sure
• Which vendor capability would make you choose a commercial platform over building internally? Options: Faster time to value (weeks vs months), Lower ongoing operational overhead, Centralized monitoring and alerting, Pre-built connectors for majority of apps, Stronger security and compliance support
• If an internal build matched the vendor on cost and features, would your procurement process still prefer the vendor option? Options: Yes, vendor preferred, No, internal build preferred, Depends on support and SLA terms

What must be in place before we start

• Which of these prerequisites is currently missing and would block kickoff? Options: API access to key systems, Dedicated integration owner/resource, Accessible test environments, Representative sample data sets, Security / compliance approvals, Network/VPN access to on-prem systems
• Who owns the APIs for the systems in scope and how quickly can they provide credentials or client access? Options: Internal application team, <2 weeks, Internal application team, 2–6 weeks, Third-party vendor, timeline uncertain, APIs not available
• What authentication and authorization models must the platform support for your systems (select all that apply)? Options: OAuth2, API keys, Mutual TLS, SAML/SSO, Kerberos / NTLM, On-prem network appliances
• If you cannot provide a dedicated integration resource within 4 weeks, should we pause the engagement? Options: Pause until resource is available, Proceed with vendor-managed work and shadowing, Reduce scope to what we can staff internally, Unsure
• Provide the desired project kickoff date and any fixed go-live deadlines we must meet

How you'll decide to move forward

• Which measurable signal would make you sign a purchase order within 30 days after a successful pilot? Options: Demonstrated mapping accuracy on representative dataset, Sustained throughput at expected peak, Clear error visibility and automated retries, Security review passed, TCO estimate within budget expectations
• Which KPIs will your leadership expect to see improved to justify expansion (select up to three)? Options: MTTR for integration incidents, Number of unmanaged point-to-point integrations reduced, Integration-related support tickets, Time to build a new connector, Operational cost of integration per month
• Who is the final approver for procurement and what single metric will sway their decision fastest?
• If the pilot meets every agreed acceptance criterion, what internal process or dependency could still delay contracting? Options: Legal/contract review, Budget reallocation, Executive re-prioritization, Procurement timelines, Nothing, we can execute quickly

Concrete next steps, owners, and timeline

• If the pilot proves the expected savings, what is the earliest realistic date your organization could commit to a deployment contract? Options: Within 2 weeks, 2–6 weeks, 6–12 weeks, More than 12 weeks, Not sure
• Which roles must be named as owners before work starts (select all that must be assigned)? Options: Executive sponsor, Integration owner (day-to-day), Security/compliance owner, Application owner for each endpoint, Data owner for reporting/warehouse, Procurement point of contact
• Do you have budget already allocated to proceed if the pilot succeeds? Options: Yes, fully allocated, Partially allocated, need approval, No, would require new budget request, Unsure
• What is the single next action you want from the vendor after this discovery call? Options: Technical scoping session with engineers, Pilot proposal with acceptance criteria, Security and compliance questionnaire, Commercial terms estimate, Other

• decision_readiness
• success_criteria
• current_state
• desired_state
• gaps
• stakeholders
• decision_readiness
• desired_state
• gaps
• success_criteria
• current_state
• stakeholders
• decision_readiness
• current_state
• desired_state
• stakeholders
• success_criteria
• gaps
• decision_readiness
• decision_readiness
• decision_readiness
• decision_readiness

• Deploy Pre-built Connector for Source Application
• Build Visual Integration Flow Between Endpoints
• Implement Data Transformation and Mapping Rules
• Create Custom Connector for Unsupported Endpoint
• Provision On-premises Integration Agent
• Configure Error Handling and Automatic Retries
• Configure Centralized Monitoring and Alerting Dashboard
• Migrate Legacy Point-to-Point Integrations
• Perform Historical Data Sync and Backfill
• Execute High-Volume Throughput and Reliability Tests
• Configure API Management and Rate Limiting
• Enable Event-Driven Workflow Orchestration
• Deliver Hands-on Developer Training on Platform

Deploy Pre-built Connector for Source Application

• Do you already use a pre-built connector for your source application instance in the platform connector library? Options: Yes, No, Partially - requires patching
• Which API version does the source application's primary endpoint expose (provide version string or 'unknown')? Options: v1, v2, v3, Unknown / custom
• Provide the expected peak transactions per second (TPS) or messages per minute from the source application at go-live. Options: <1 TPS, 1-10 TPS, 10-100 TPS, >100 TPS
• Specify any custom objects or custom fields in the source application that must be included; name the API resource or field API names.
• Identify the authentication method available for the connector (OAuth2, API key, basic auth) and whether you can provide test credentials for a staging instance. Options: OAuth2, API key, Basic auth, Certificate
• What acceptance criteria will confirm the pre-built connector is production-ready (examples: 99.9% success rate over 24 hours, <1% transform error, sustained 1-hour TPS target)?

Build Visual Integration Flow Between Endpoints

• List the source-to-target data flows you need modeled (for example: contact sync, order -> invoice, inventory update) in priority order.
• Do the listed flows require bi-directional synchronization or one-way replication for each flow? Options: One-way (source to target), One-way (target to source), Bi-directional
• Which message format will carry the payloads for each flow (JSON, XML, CSV, fixed-width) and do you have schema artifacts? Options: JSON, XML, CSV, Other / Mixed
• Provide a field-level mapping example for a representative record type (for example: contact -> accountName, email -> primaryEmail) or upload a sample mapping file.
• Are there business rules that must trigger branching in the visual flow (for example: skip if order total < 50 USD; route refunds to reconciliation queue)? Options: Yes, No
• Who on your team will approve the visual flow design and validate test runs?

Implement Data Transformation and Mapping Rules

• For each target entity, list the transformation steps required (normalize phone, split address lines, map currency codes) with at least one concrete example.
• Attach or paste a sample source payload (obfuscated) for contact, order, and inventory messages to guide transformation design.
• How many custom transformation functions do you anticipate needing (examples: normalizeTaxId, flattenNestedLines)? Options: 0, 1-5, 6-15, 16+
• Indicate whether transformations must run synchronously in-line with API requests or asynchronously in batch for each flow. Options: Synchronous (in-line), Asynchronous (batch)
• Confirm whether you require data validation against a schema registry or business rules (for example: required fields, value ranges) before writing to the target system. Options: Yes - schema registry, Yes - business rules, No validation required
• Who will own maintenance of mapping rules after handover and what change workflow do you prefer (pull request, UI edit, ticket)? Options: Pull request, UI edits, Ticket-driven

Create Custom Connector for Unsupported Endpoint

• Does the unsupported endpoint expose a public API or is access provided only via a vendor-supplied on-prem agent? Options: Public API, On-prem agent only, Both
• Specify the endpoint base URL pattern and supported authentication modes for the custom connector (include OAuth scopes or certificate types).
• Estimate the number of unique API resources and operations required to support the integration (for example: 12 endpoints for orders, 5 for inventory). Options: 1-5, 6-15, 16-50, 50+
• Identify documented rate limits or throttling windows for the unsupported endpoint (requests per minute/hour) and any burst allowances.
• Are there published SDKs, client libraries, or existing connector code we can reuse? Options: Yes - SDKs, Yes - sample code, No
• List the name and role of the person who can provide a non-production sandbox and API keys for connector development.

Provision On-premises Integration Agent

• Where will the on-premises agent be hosted (data center rack, VMware cluster, corporate cloud VPC) and what operating system will it run? Options: Linux, Windows, Other
• Indicate the network egress IP addresses, proxy configuration, and firewall rules required for the agent to reach the platform endpoints.
• Confirm whether the agent must connect through a reverse proxy, go directly outbound, or use a site-to-site tunnel. Options: Reverse proxy, Direct outbound, Site-to-site VPN
• What host resource capacity will you allocate to the agent (CPU cores, memory, disk) to support peak message throughput?
• For hosts that process regulated data, state required controls and maintenance windows needed for agent installation (examples: change window, privileged access approval).
• Give the contact email and pager for the on-prem technical owner who will approve the agent deployment and provide host credentials.

Configure Error Handling and Automatic Retries

• Describe the error categories you want classified (transient network, schema mismatch, authorization failure) and desired handling for each.
• State the maximum retry count and backoff policy you want applied for transient API call failures. Options: No retries, 3 retries - linear, 5 retries - exponential, Custom
• Name the HTTP status codes or platform error codes that should be treated as terminal (no retry) for order and customer endpoints.
• Measure the acceptable time-to-recovery for transient failures before triggering an escalation (for example: 15 minutes, 1 hour). Options: 15 minutes, 30 minutes, 1 hour, 4 hours
• Does your compliance program require that failed payloads containing PHI or PCI never be logged in plain text? Options: Yes, No
• State the recipients and ticketing queue names that should receive dead-letter notifications for failed payloads.

Configure Centralized Monitoring and Alerting Dashboard

• Outline the key metrics you need on the central dashboard (connector health, queue depth, error rate, average latency) and initial alert thresholds.
• Name the user roles that should have dashboard access and describe their required view or edit permissions.
• Describe a sample alerting escalation path for a sustained connector outage that lasts longer than 15 minutes.
• Select whether you require on-call rotation integration with your paging system or only email notifications for alerts. Options: Pager integration, Email only, Both
• Indicate the log retention window required for dashboard-linked logs (30 days, 90 days, custom) and whether logs must be exported to your SIEM. Options: 30 days, 90 days, Custom
• Name the dashboard owner who will be responsible for triage and adjusting alert thresholds post-launch.

Migrate Legacy Point-to-Point Integrations

• Attach an inventory (spreadsheet or document) of legacy point-to-point integrations to be migrated including source system, target system, data types, and current owner.
• Estimate the effort level for each legacy integration based on available interface documentation and need to reverse-engineer logic. Options: Low (documented), Medium (partial docs), High (undocumented)
• Does any legacy integration depend on hard-coded credentials, file-system drops, or stored procedures that will require special migration steps? Options: Yes - credentials/files, Yes - stored procedures, No
• What migration acceptance criteria will define success for each legacy integration (examples: 99.95% data parity post-cutover, zero lost orders over a 7-day validation window)?
• Which legacy integrations are explicitly out of scope for this engagement (for example: proprietary middleware requiring separate vendor licensing)? Options: None - all in scope, Specific list - will provide, Negotiable
• Who will sign off on migration cutover and who is enabled to approve rollbacks during cutover windows?

Perform Historical Data Sync and Backfill

• Which entities require historical sync (contacts, orders, invoices) and what is the record count per entity?
• Provide the acceptable data accuracy threshold for backfill validation (for example: 99.9% field-level parity) and the comparison method. Options: 99.9%+, 99.0-99.9%, <99%
• Estimate the total volume (GB or number of rows) and any time-window constraints for performing the backfill.
• Are there archival stores, deleted records, or GDPR/PII restrictions that limit what historical data can be migrated? Options: Yes - archival/retention rules apply, No restrictions, Need to review retention policy
• What validation plan will you use to confirm backfill completeness (checksum comparison, row counts, spot-checking sample records)? Options: Checksum/row counts, Sample record checks, Both
• What SLA or acceptance evidence will you require to sign off on the historical sync (examples: reconciliation report, parity percentage, sample record sign-off)?

Execute High-Volume Throughput and Reliability Tests

• Which integration flows should be included in high-volume testing (order ingestion, inventory updates, billing events)?
• State target throughput goals for each flow in transactions per second (TPS) or messages per minute for performance validation.
• Describe any realistic failure modes to simulate during tests (API timeouts, partial payloads, schema drift).
• Do you require soak testing for more than 24 hours to validate memory leaks or queue growth under continuous load? Options: Yes - soak test required, No - burst testing only
• Indicate the success thresholds for reliability tests (example: 99.95% success over test window, median latency < 200 ms).
• Who will approve the performance test plan and attend the test-run review to accept results?

• Master Services Agreement (MSA)
• Subscription Order Form
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Acceptance and Go‑Live Criteria
• Support & Escalation Matrix Addendum
• Change Order Agreement
• Data Processing Agreement (DPA)

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• Acceptance Gate Decision (around day 90)
• Quarterly Operational Review
• Six-Month Adoption and Handover Review

• Update the operational dashboard with agreed reporting windows and assign remediation timelines for high-priority incidents.
• Publish the acceptance decision record with criterion-level outcomes and any conditional remediation timelines.
• If incumbent is decommissioned, produce an archival and rollback checklist and schedule the decommissioning runbook execution.
• Document remaining conditional items with resolution owners and target close dates where acceptance was not fully met.
• Dashboard health and trend review
• Operational metrics including connector uptime and transaction latency are reviewed and placed on a remediation or sustainment track.
• High-priority incidents and enhancement requests have clear next steps and target completion windows.
• The buyer's self-service readiness status is updated and any remaining enablement gaps are scheduled for action.
• Re-confirm success criteria and owners
• Publish a deliverables schedule for the next quarter listing enhancement requests committed for delivery and verification criteria.
• Deliver the updated runbook and a short enablement checklist to validate buyer team self-service capability.
• Adoption metrics and business impact
• Active integration count and reduction in manual reconciliation hours are measured and compared to Solution Scope targets.
• A clear plan to eliminate remaining seller dependencies is agreed with timelines.
• Enhancement requests are triaged into scheduled delivery, buyer-handled, or deferred categories with review cadence defined.
• Produce a handover plan that lists remaining seller-managed tasks, target completion dates, and the acceptance criteria for full self-service.
• Publish a prioritized enhancement schedule showing which items will be implemented, which will be handed to buyer-owned queues, and expected delivery windows.
• Deliver a short operational readiness checklist for the buyer to declare full self-service and monitor that checklist over the next 30 days.
• Deployment and basic connectivity confirmed for the primary integration flows.
• Critical open incidents and blockers are triaged and assigned resolution windows.
• Owners and escalation paths for first 90 days are documented and acknowledged by attendees.
• Publish a short remediation tracker listing each critical issue, expected resolution date, and verification steps.
• Run a verification pass for the primary integration flows and report results before the first measurement meeting.
• Present first measurement data
• Connector uptime and integration error rate are measured and explained relative to the targets recorded in Solution Scope.
• A prioritized list of corrective actions with completion dates is agreed for any failing metrics.
• Timeline to the acceptance gate is confirmed and documented.
• Deliver a corrective action plan with steps, success criteria, and resolution dates for each identified root cause.
• Schedule targeted verification runs and capture measurement snapshots for the acceptance gate meeting.
• Restate acceptance criteria and numeric targets
• Each acceptance criterion from Solution Scope is evaluated and recorded as pass, conditional pass, or fail.
• A documented acceptance decision is produced and appropriately signed for this engagement type.
• The incumbent system wind-down status, data archival, and any required retention steps are agreed and scheduled.
• Root cause analysis for gaps
• Open incidents and enhancement request review
• Operational independence assessment
• Present outcome data against each criterion
• Deployment and migration validation
• Document pass, conditional pass, or fail per criterion
• Corrective actions and timeline
• Early adoption signals and usage patterns
• Outstanding dependencies and transition plan
• Self-service readiness and enablement status
• Agree quarterly remediation and delivery plan
• Open defects and blockers
• Enhancement request disposition
• Formal acceptance decision and signatory capture
• Confirm path to acceptance gate
• Incumbent system wind-down and data archiving
• Agree immediate remediation actions