Integration fit and platform constraints

• Which integration architectures or interface types are currently in scope for this effort? Options: Custom point-to-point interfaces, On-prem enterprise service bus or middleware, Cloud integration platform / iPaaS, Database replication or ETL pipelines, Batch file interfaces (SFTP/flat files), API-based integrations, Unknown / need help mapping, Other
• Will any regulated or sensitive data be processed or stored by these integrations? Options: No regulated data, Health data (PHI), Payment or financial data, Personal identifiable information (PII), Data residency or localization requirements, Unsure, Other
• Are there technical or access constraints that would prevent the seller from running a short discovery or proof-of-concept (for example, restricted network access, no vendor accounts, or paused change windows)? Please describe briefly.

Budget

• Is there an allocated budget range for integrations and migration work? Options: Under $50,000, $50,000–$200,000, $200,000–$500,000, $500,000–$1,000,000, Over $1,000,000, No allocated budget yet / exploring

Decision process and authority

• Who will sign the final contract or formally approve this project? Options: VP of Enterprise Architecture, CIO / IT Executive, IT Director / Head of Integrations, Procurement or Sourcing, Cross-functional steering committee, Other
• What procurement or approval path should we expect (for example, direct IT approval, formal RFP, procurement review, or executive sign-off)? Options: Direct technical/IT approval, Formal RFP or tender, Procurement-led review with shortlist, Executive-level approval required, Unsure / still forming

Timeline and next-step readiness

• What is the target date or driver that makes the timing important? Options: Merger or consolidation deadline, ERP end-of-life or decommissioning, Board-mandated cloud migration date, Business-critical seasonal deadline, No fixed date / exploratory, Unsure
• To determine whether a full discovery is worthwhile, would you be available for a 60–90 minute technical workshop in the next two weeks? Options: Yes — please propose times, Yes — but need to confirm internally first, Not in next two weeks, but within a month, Not ready for full discovery yet, Unsure

Mapping today's integration landscape

• How would you briefly describe your current integration landscape in one sentence?
• Which primary application categories must be connected as part of this effort? Options: ERP / Finance systems, CRM / Sales systems, Order management / OMS, HR / Payroll, Data warehouse / BI, Custom legacy systems, Other
• Tell me about the last time an integration change caused production impact, what happened and how long did it take to resolve?
• On a typical peak day, how many transactions or messages move through your most critical connectors? Options: Under 1k, 1k–10k, 10k–100k, 100k–1M, Over 1M, Unknown
• Who on your team currently owns running and monitoring integrations day to day? Options: Central integration team, Platform engineering, Application owner teams, Managed service / vendor, No clear owner

Where the integration pain actually lives

• What single integration failure in the last 12 months would have made you escalate to the executive team immediately?
• Walk me through that incident from first alert to resolution, including who was notified and what tools you used to troubleshoot.
• When those failures occur, which downstream processes are affected first and what measurable business impact follows? Options: Order delays / missed SLAs, Billing reconciliation errors, Customer experience incidents, Reporting inconsistencies, Operational manual work, Other
• Which logs, dashboards, or reports do you currently trust to tell you integration health is deteriorating? Options: Application logs, Message queue metrics, ETL/data reconciliation reports, Custom monitoring dashboards, None / ad hoc checks
• If a connector failed during a planned peak window, what minimum mitigation would you accept to avoid delaying the business activity? Options: Retry and catch-up within 1 hour, Temporary manual reconciliation, Rollback to previous system, Partial cutover with limited scope, Delay is unacceptable

Drivers, deadlines, and hidden trade offs

• When the executive team agreed to this deadline, what trade offs were accepted that could still surface as risks?
• What internal or regulatory dates are immovable and would force a hard pause if not met? Options: Board reporting date, Contractual go-live, Regulatory deadline, End of vendor support, Quarter close, Other
• Name the stakeholders pushing for the earliest go live and the business outcomes they have tied to that date.
• Describe a recent project where timeline pressure led to technical shortcuts, and what cost or rework followed.
• If your target date shifted by more than two weeks, who can stop the program and on what grounds?

What success looks like in hard numbers

• What measurable outcomes would make leadership call this integration successful within six months?
• List the top three KPIs you will use in pilot and production to judge performance and reliability. Options: Message throughput (msgs/sec), End to end latency (p95/p99), Data reconciliation error rate, MTTR for incidents, Success rate for transactional flows, Operational cost reduction
• In the pilot, what threshold of data reconciliation errors or duplicates would be unacceptable for you to proceed? Options: >0.1%, >0.5%, >1%, >2%, Any unreconciled items unacceptable
• Provide the throughput, latency, and error rate targets that must be met during pilot to consider it a technical success.
• Assuming pilot meets those KPIs, who or what could still block the decision to proceed to full rollout and why?

Operational readiness and hard constraints

• What integration dependency, if unavailable at cutover, would force you to delay go live?
• List every third party or internal system that must expose an API or service and whether that interface is currently documented and accessible. Options: Documented and accessible, Documented but not accessible, Undocumented but available, No interface available yet
• Do you have at least two engineers who can be dedicated to integration and cutover activities during the migration window? Options: Yes, allocated full time, Yes, part time allocation, No, we would need to hire or reassign, Undecided
• On your data readiness, what percent of core records (customers, products, suppliers) are cleansed and free of duplicate keys? Options: >95%, 80%–95%, 50%–80%, <50%, Unknown
• Are there security reviews, legal approvals, or contract sign offs that could add more than four weeks to the schedule? Options: Yes, security approval required, Yes, legal or procurement approval required, No major approvals expected, Unknown / need to check
• Name the role that must grant final production credentials and whether they have committed to a date for providing access. Options: Platform owner, Security team, Infrastructure owner, Application owner, No committed role/date

The other paths on the table

• Tell us which alternatives you are actively weighing, including keeping the incumbent, going internal, or other vendors. Options: Stay with incumbent vendor, Build internally, Evaluate other system integrators, Use managed service, Replace with SaaS integration product
• Name any incumbent vendors or managed teams currently supporting these integrations today.
• What would have to be true about your current approach for your team to keep it rather than start a replacement project?
• Has anyone internally proposed solving this without an outside partner, and if so what resourcing plan did they outline? Options: Yes, internal team with current headcount, Yes, internal with new hires planned, No formal internal plan proposed, Unknown
• If you chose to stay with the incumbent or go internal today, what single barrier would prevent switching to an external integrator within the next quarter?

Decision makers, governance, and the cutover authority

• Who must sign commercial and operational acceptance to move from pilot to production, and what evidence will satisfy them?
• Which governance forum meets weekly to clear deployment blockers and who represents integration there? Options: Program steering committee, Change control board, SRE / Ops forum, Architecture review board, No standing forum
• Estimate the internal cost of a failed cutover in the first month, including remediation, downtime, and customer impact. Options: Under $50k, $50k–$250k, $250k–$1M, Over $1M, Unknown / needs analysis
• What is the fastest decision path that would allow you to sign a statement of work within one week after a successful pilot? Options: Single executive sign off, Finance and legal sign off required, Procurement and contracting required, Multiple committee approvals required
• If the pilot proves the outcomes you expect, who on your side has the authority to commit to staffing and budget in the same week?

• Solution Experience Session: Integration Architecture & Runbooks

• Confirm the current state and what it is costing
• You confirm the demonstrated architecture and runbook eliminate the reconciliation failures and meet the agreed cutover downtime target.
• Provide peak transaction volumes, expected peak windows, and a representative sample dataset for load validation.
• You confirm the provided test evidence shows the integration meets peak throughput and failover acceptance criteria.
• Walk the proposed integration architecture using your systems
• Confirm approved cutover windows and escalation contacts for each migration wave.
• Deliver a validated cutover runbook and a load test report mapped to the provided volumes before the follow-up technical decision session.
• You agree that the knowledge transfer plan and shadowing schedule leave your team able to operate and extend the integration layer after handover.
• Runbook walkthrough for cutover, rollback, and monitoring
• Schedule three days of shadowing and two 90-minute operations training sessions during the runbook dry run phase.
• Agreement on the remaining technical evidence required before a procurement decision.
• Review capacity and resilience evidence against your scenarios
• Confirm the knowledge transfer and operational handover plan
• Identify the single point of contact who will accept the operational handover.
• Forced validation, confirm this matches your needs

• Solution Experience Session: Integration Architecture & Runbooks
• Solution Experience Deck
• Solution Brief: Integration Architecture & Runbooks

• meeting
• slides
• document

• Deploy integration middleware platform
• Develop API layer and gateways
• Build reusable integration patterns
• Migrate ERP master and transactional data
• Migrate CRM and contact records
• Execute batch migration and reconciliation
• Implement real-time data pipelines
• Bridge on-premise and cloud endpoints
• Implement error handling and retry logic
• Run performance and load testing
• Perform cutover and go-live execution
• Deliver operational runbooks and handover
• Decommission legacy point-to-point integrations
• Implement monitoring, alerting, and health checks
• Execute data cleansing and quality remediation

Deploy integration middleware platform

• Which topology do you require for the middleware (single-node, active/active cluster, active/passive)? Options: Single-node, Active/passive cluster, Active/active cluster, Unsure — need recommendation
• How many middleware instances will map to your production, staging, and DR (disaster recovery) environments? Options: 1 production, 1 staging, 1 production, staging and DR, Multiple per region, Unsure
• Who will provide the infrastructure for middleware (your cloud account, on-premise VMs, or a managed environment)? Options: Your cloud account, On-premise VMs, Managed hosting by third party, Combination
• Describe expected peak sustained throughput for the middleware in messages per second and peak concurrent connections (include typical transaction size in KB).
• Provide any compliance or network constraints for the middleware deployment (for example, private subnet only, restricted egress, or specific encryption requirements).

Develop API layer and gateways

• Identify the primary API consumers that will call the gateway (mobile apps, order management system, B2B partners, other back-office systems). Options: Mobile apps, Order management, B2B partners, Back-office systems, Other
• Which authentication schemes must the gateway support for those consumers (OAuth 2.0, mutual TLS, API key, SAML)? Options: OAuth 2.0, Mutual TLS, API key, SAML, Other
• How many distinct API endpoints (surface area) do you expect to expose initially for external integration (REST resources, SOAP endpoints, GraphQL operations)? Options: Less than 10, 10-50, 51-200, More than 200, Unsure
• Specify the SLA target for API response time under normal load for key endpoints (for example, order lookup under 300 ms).
• When integrating gateways with the middleware, which existing artifacts should we reuse (API specification documents, OpenAPI/Swagger files, WSDLs)? Options: OpenAPI/Swagger, WSDL, Internal API spec documents, No existing artifacts

Build reusable integration patterns

• List the common integration scenarios to be templated (order-to-cash, invoice posting to GL, customer master sync, inventory update).
• Which message formats must the patterns support out of the box (JSON REST, XML SOAP, EDI X12, flat file CSV)? Options: JSON REST, XML SOAP, EDI X12, Flat file (CSV/TSV), Other
• How many connectors should a reusable pattern cover initially (e.g., connector to your source ERP, target data lake, and SFTP partner)? Options: 1-2 connectors, 3-5 connectors, 6+ connectors, Unsure
• Describe the degree of configurability required for patterns (parameterized field maps, pluggable transforms, dropdown configuration versus code changes).
• Identify any regulatory or ledger rules that reusable patterns must enforce (for example, chart of accounts validation, tax jurisdiction mapping, or audit trail headers).

Migrate ERP master and transactional data

• Which ERP domains and artifacts require migration (chart of accounts, vendor master, customer master, item/SKU master, open sales orders, open purchase orders, AR/GL balances)? Options: Chart of accounts, Vendor master, Customer master, Item/SKU master, Open sales orders, Open purchase orders, AR/GL balances, Other
• How many historical months of transactional history must be migrated for reporting and reconciliations (for example, 12 months of invoice and payment history)? Options: None, 3 months, 6 months, 12 months, 24+ months
• Specify the target data accuracy threshold for migrated master and transactional records (for example, customer master match rate >= 99%).
• Which artifacts will be used to validate migration completeness (for example, trial balance, GL reconciliation report, open order list)? Options: Trial balance, GL reconciliation, Open order report, Customer aging, Other
• What defines final acceptance for the ERP migration in measurable terms (completeness, reconciliation tolerances, and performance of migrated transactional queries)? Options: Completeness thresholds and reconciliation sign-off, Automated reconciliation report within tolerance, Manual stakeholder approval, Combination

Migrate CRM and contact records

• Which CRM data domains require migration (contact records, accounts, opportunities, activity history, custom objects)? Options: Contact records, Accounts, Opportunities, Activity history, Custom objects, Other
• How many contact records and accounts need migrating and how many custom fields must be mapped? Options: Less than 10k, 10k-100k, 100k-1M, More than 1M
• Which deduplication rule will you apply to contact records (email match, phone match, name+address fuzzy match)? Options: Email match, Phone match, Name+address fuzzy, Custom rule set
• Who owns final validation of migrated CRM data (sales operations, CRM admin, or a named business analyst)? Options: Sales operations, CRM admin, Business analyst, Other
• Provide examples of CRM reports or dashboards that must match pre-migration values after cutover (pipeline totals, open opportunities by owner).

Execute batch migration and reconciliation

• For batch jobs, which data extracts and file layouts will be used (journal export, invoice batch CSV, AR aging export)?
• How many parallel batch windows exist and what are their scheduled runtimes (nightly GL feed at 02:00, daily invoice batch at 03:00)?
• What reconciliation reports must be automated post-batch (record counts, hash totals, financial sum checks)? Options: Record counts, Hash totals, Financial sum checks, Custom reconciliation
• Estimate acceptable reconciliation tolerance for numeric mismatches (for example, GL variance <= $250 or 0.1%).
• Which stakeholder will be the reconciliation owner and approver for each batch load (finance lead, data steward, integration owner)? Options: Finance lead, Data steward, Integration owner, Other

Implement real-time data pipelines

• Which source systems will publish change data capture streams (ERP change logs, CRM CDC, database binlogs)? Options: ERP change logs, CRM CDC, Database binlogs, Message bus events, Other
• What is the maximum acceptable end-to-end latency for real-time pipelines (for example, customer update visible in downstream systems within 5 seconds)? Options: Sub-second, 1-5 seconds, 5-30 seconds, 30+ seconds
• Which downstream consumers require the real-time feed (order processing engine, inventory service, billing engine)? Options: Order processing, Inventory service, Billing engine, Analytics, Other
• Describe the expected event volume per minute and average event payload size for peak periods.
• Identify required ordering or idempotency guarantees for events (per-aggregate ordering, at-least-once, exactly-once semantics). Options: At-least-once, At-most-once, Exactly-once, Per-aggregate ordering required

Bridge on-premise and cloud endpoints

• Which on-premise endpoints must be bridged (legacy ERP database, EDI VAN, SFTP at customer DMZ)? Options: Legacy ERP DB, EDI VAN, SFTP, SOAP endpoints, Other
• Which connectivity method is available for on-premise bridging (site-to-site VPN, dedicated circuit, reverse proxy tunnel)? Options: Site-to-site VPN, Dedicated circuit, Reverse proxy/tunnel, Agent-based connector
• What firewall or network constraints must we accommodate (specific IP allowlist, port restrictions, deep packet inspection)?
• Who administers on-premise endpoints and will approve installation of any local connector/agent? Options: Your network team, On-premise ops, Third-party hosting provider, Other
• When bridging to cloud, what data residency or encryption-at-rest requirements apply for persisted data (for example, AES-256, key management in your cloud account)?

Implement error handling and retry logic

• Which integration surfaces require guaranteed delivery versus best-effort (financial posting versus analytics events)? Options: Guaranteed delivery, Best-effort, Mixed — specify per interface
• How many retry tiers are acceptable for transient failures and what are backoff windows (immediate, 5m backoff, exponential up to 1 hour)? Options: Immediate + fixed retries, Exponential backoff, Custom schedule
• Identify specific business error codes that should route messages to a dead-letter queue and which should trigger manual intervention (for example, 4xx client errors vs 5xx backend errors).
• What visibility do you require into retry activity and failed messages (dashboard, alert per failure, daily summary)? Options: Dashboard, Per-failure alert, Daily summary, Weekly report
• Describe the acceptable data retention period for failed messages and dead-letter archives for audit and reprocessing purposes. Options: 7 days, 30 days, 90 days, Custom

Run performance and load testing

• What peak virtual users or TPS (transactions per second) should load tests simulate for key flows like order submission and invoice posting?
• Which test scenarios must be included (concurrent order bursts, bulk invoice import, sustained CDC stream at peak volume)?
• What performance thresholds must be met during tests (p95 latency under X ms, no data loss for CDC streams)?
• Who will provision test environments that mirror production network and data volume characteristics? Options: Your cloud team, On-prem ops, We provision test environment, Combination
• How will you validate test results — automated pass/fail criteria or manual review by performance engineer? Options: Automated pass/fail, Manual review, Both

Perform cutover and go-live execution

• Which business processes must be frozen or paused during cutover (order entry, GL posting, EDI exchange windows)?
• When is your preferred cutover window and how many hours of blackout are acceptable for impacted systems? Options: Weeknight 02:00-06:00, Weekend 48-hour window, Business hours not acceptable, TBD
• What rollback criteria will trigger reverting to the legacy integration (for example, reconciliation variance > threshold, critical transaction failures > X per minute)?
• Who will be on the cutover war room roster and which escalation path should be followed for P1 failures?
• What evidence will validate a successful go-live for cutover (for example, reconciliation reports within tolerance, successful end-to-end order placement and fulfillment)? Options: Reconciliation within tolerance, Successful E2E test transactions, Stakeholder sign-off, All of the above

Deliver operational runbooks and handover

• Which runbook artifacts do you require at handover (sequence diagrams, step-by-step playbooks, escalation contact list, rollback procedures)? Options: Sequence diagrams, Step-by-step playbooks, Escalation contact list, Rollback procedures, All of the above
• Who on your team will be the primary runbook owner responsible for updates post-handover? Options: Integration team lead, Platform ops, Application owner, To be assigned
• What format do you prefer for operational artifacts (PDF playbooks, runbooks in wiki pages, executable runbook scripts)? Options: PDF playbooks, Wiki pages, Executable runbook scripts, Other
• What training sessions are required for knowledge transfer (admin operations, developer onboarding, runbook walkthroughs) and how many attendees per session?
• What constitutes accepted handover evidence for operations (signed checklist, 30-day shadow support period, successful runbook-driven incident resolution)? Options: Signed checklist, 30-day shadow support, Successful playbook run

• Master Services Agreement (MSA)
• Statement of Work (SOW)
• Commercial Terms & Order Form
• Service Level Agreement (SLA)
• Staffing and Certification Roster
• Acceptance Criteria and Test Plan
• Governance and Escalation Plan
• Change Order Agreement
• Knowledge Transfer and Handover Plan
• Compliance and Regulatory Addendum

• Go-Live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• SLA and Operational Handover Ratification (60-90 days)
• Monthly Operational Burn-down (monthly during hypercare)
• Quarterly Realization Review

• Close or reclassify tickets that no longer meet the criticality threshold and update the ticket owner list.
• Confirm the knowledge transfer checklist is complete and runbooks are published to the operational team.
• Agree the incumbent system decommission approach and the timeline to archive or set it to read-only.
• Publish final operational runbooks and monitoring dashboards to the agreed access location.
• Execute the incumbent system wind-down tasks, including data archive verification and read-only enforcement.
• Configure SLA alerting that notifies the operational owner when integration uptime approaches breach thresholds.
• Ticket burn-down and severity review
• Demonstrate measurable reduction in open high-severity tickets through agreed closure plans.
• Ensure integration uptime remains within SLA thresholds and any deviations have assigned corrective actions.
• Agree the top operational enhancements to schedule into the next maintenance window.
• Reconfirm acceptance criteria and owners
• Publish required runbook updates and mark sections that need additional training.
• Prioritize the enhancement backlog and schedule the top items for the next maintenance window.
• Quarterly metrics presentation
• Verify whether user adoption rate and month-end close cycle time meet the targets recorded in Solution Scope or require a multi-quarter remediation plan.
• Agree the prioritized set of operational improvements and owners for the next quarter.
• Confirm the governance cadence for ongoing metric reporting and escalation for unresolved gaps.
• Publish the quarterly realization report that maps metric performance to Solution Scope targets and lists agreed improvements.
• Create a quarter-long improvement plan for any metric not meeting target, including verification criteria and completion dates.
• Update SLA documentation if monitoring thresholds or escalation paths were changed in the meeting.
• Validate that the deployment completed against the migration validation checks recorded in Solution Scope.
• Identify and document the top open production issues and agree remediation tasks and timelines.
• Confirm the owners who will verify closure of each high-severity item before the first measurement meeting.
• Publish the post-deployment validation summary that maps observed results to Solution Scope acceptance rows.
• Create the high-severity incident list with target resolution dates and verification steps.
• Enable basic monitoring dashboards and alerting for key integration endpoints.
• Present first-run data versus targets
• Decide whether integration uptime and data migration completeness are tracking to the targets recorded in Solution Scope or require corrective plans.
• Approve a time-bound remediation plan for any failed metrics with verification criteria.
• Agree who will publish the measurement report and the date for the next operational checkpoint.
• Deliver the measurement report showing metric trends, raw data extracts, and variance analysis versus Solution Scope targets.
• Open remediation tickets for each failed metric with clear verification steps and target completion dates.
• Schedule a technical detailed review for any metric with unclear root cause within 7 days.
• SLA performance review
• Validate SLA metrics and either ratify operational readiness or document required remediation with dates.
• Deployment and migration validation
• Root-cause diagnosis for gaps
• Business impact and open issue review
• Knowledge transfer completion checklist
• Recent incidents and root-cause updates
• Operational runbook and monitoring handover
• Enhancement roadmap for operational improvements
• Agreement on corrective actions and timelines
• Enhancement and backlog prioritization
• Early adoption signals and usage patterns
• Incumbent system wind-down
• Open blockers and incident triage
• Governance and monitoring adjustments
• Confirm path to stabilization milestone
• Runbook and knowledge gaps
• Outstanding remediation closure plan
• Agree immediate remediation actions
• Agree focus for next month
• Publish measurement outcomes