Starting Somewhere: Tell Us About What Brought You Here

• What's the trigger that brought you to consider an integration project right now? Options: Merger / acquisition consolidation, ERP end-of-life / modernization, Cloud-first migration mandate, Repeated data quality incidents, Performance / scalability failures, Regulatory or audit pressure, Other
• Who is being held accountable for delivering results (name / title / team)?
• What is the target timeframe leadership expects for a working solution (not just planning)? Options: 0–3 months, 3–6 months, 6–12 months, 12+ months, TBD / flexible
• If you had to pick one headline metric leadership will use to judge success, what would it be? Options: Minimize downtime, Data quality improvements, Throughput / transaction capacity, Cost reduction, Time-to-integration for new systems, Operational handover readiness, Other
• On a scale from optimistic to worried, how would you describe the team’s confidence in meeting that timeline? Options: Very confident, Somewhat confident, Unsure, Concerned / high risk

If We Ignore This, What Gets Worse?

• What hidden costs, compliance gaps, or business risks are quietly growing because integrations have been deprioritized?
• Which business processes or revenue streams are most exposed if integrations fail or data is unreliable? Options: Order-to-cash, Procure-to-pay, Inventory / fulfillment, Finance / close processes, Customer support / CRM workflows, Analytics / reporting, Other
• How often do data discrepancies or reconciliation tasks interrupt daily operations today? Options: Daily, Weekly, Monthly, Rarely, Never
• Tell us about a recent incident where an integration problem caused measurable harm (downtime, lost revenue, compliance issue). What happened and what was the impact?
• When those problems surface, how does it affect team morale or your stakeholders’ trust? Options: Erodes trust quickly, Creates recurring frustration, Minor annoyance, Hardly noticed

Who Holds the Keys — and Who We Need to Convince

• If we mapped influence, whose support would accelerate progress — and whose opposition could stop it?
• Which roles or teams must be actively engaged for cutover to succeed? Options: ERP application owners, Network / infrastructure, Security / IAM, DBA / Data engineering, Business process owners, Third-party vendors, Other
• Who will be the day-to-day internal owner for post-go-live operations and knowledge transfer (name/title)?
• How do your key stakeholders prefer to receive updates when risks emerge (email, dashboard, weekly review, Slack/MS Teams, other)? Options: Email, Executive dashboard, Weekly review / steering committee, Slack / Microsoft Teams, Ad-hoc meetings, Other
• Which stakeholders have hard non-negotiables (e.g., no downtime during business hours, encryption standards)? Please list role and requirement.

What Would a Nightmare Cutover Actually Look Like?

• If cutover went poorly, what are the domino effects you fear most (lost orders, incorrect invoices, regulatory breach, customer churn)?
• What is the maximum acceptable downtime for each critical system during cutover? Options: Zero tolerance (no downtime), Under 15 minutes, 15–60 minutes, 1–4 hours, 4–24 hours, 24+ hours
• What data integrity thresholds must be met at cutover (error rate, duplicate rates, reconciliation tolerance)? Please be specific.
• Which systems have the least documentation or the most brittle interfaces that increase cutover risk?
• Have you run a dress-rehearsal or rollback simulation before? What went well or wrong? Options: Yes — successful, Yes — issues encountered, No — attempted but incomplete, No — never attempted

Where Does Your Data Live — and How Messy Is It?

• Which systems hold master records that must remain authoritative after consolidation (select all that apply)? Options: ERP / Financials, CRM / Customer master, MDM, Data warehouse / analytics, Legacy on-prem apps, SaaS applications, Other
• Roughly what percentage of records do you estimate will require cleansing, matching, or enrichment before migration? Options: 0–10%, 10–25%, 25–50%, 50–75%, 75–100%, Unsure / need assessment
• Do you have documented data models, field-level definitions, and canonical schemas available for the systems in scope? Options: Complete and current, Partial / outdated, Mostly undocumented, No documentation
• Are there existing data quality rules or SLAs we must enforce automatically (e.g., duplicate thresholds, reference data validation)? Please describe.
• Which regulatory or privacy constraints affect the data (PII handling, residency, encryption at rest/in transit)? Options: GDPR, CCPA, HIPAA, Local data residency, Encryption required, No specific constraints, Other

Architecture Reality Check: Are We Building on Sand or Rock?

• Given your current integration approach, are we fixing root causes or stacking temporary patches? Options: Fixing root causes, Mix of both, Mostly temporary patches, Unsure — need analysis
• What middleware, ESB, iPaaS, or custom frameworks are currently in production and must be supported or retired?
• Are there platform constraints we must respect (on-prem only, approved cloud providers, vendor lock-in concerns, specific security certifications)? Options: On-prem only, Specific cloud provider(s) required, No cloud vendors allowed, Must meet specific certifications (list), Flexible
• Do you have reusable integration patterns, libraries, or previous IP we should leverage — or should we start fresh? Options: Significant reusable assets, Some reusable pieces, Little to none, Unsure — need review
• What non-functional requirements are critical (throughput, latency, failover RTO/RPO, concurrency)? Please list targets where known.

Success Signals: What Will Actually Make You Sleep Easier?

• If this project only achieved one measurable outcome, which would you choose? Options: Zero unplanned downtime, Verified data quality at X% accuracy, Sustained transaction throughput at target volume, Complete internal ownership after handover, Significant cost savings
• Which of these success indicators will be validated with production-like traffic and real transactions? Options: Performance under load, End-to-end data integrity checks, Business process completion rates, Error and exception rates, All of the above
• What post-go-live KPIs and SLAs will your organization require from the integration platform?
• How soon after go-live do you expect the solution to demonstrate measurable ROI? Options: Within 3 months, 3–6 months, 6–12 months, 12+ months, Not sure
• Who will certify that success signals are met and sign off on cutover acceptance?

People, Process, and Practicalities: What Will We Need to Execute?

• What internal roles can you commit to the project (full-time and part-time) — list number and function (e.g., 2 FTEs integration engineers, 1 DBA)?
• Are there scheduled business blackout windows or seasonal peaks that will constrain testing or cutover timing? Options: Weekly blackout windows, Monthly close periods, Quarterly peaks, Year-end close, No constraints, Other
• What is your budget posture for this initiative right now? Options: Approved and available, Allocated but needs final approval, Budget under discussion, Cost must be minimized, Unsure / TBD
• What legal, procurement, or vendor-governance steps typically slow contract finalization in your organization?
• Which escalation paths and decision triggers should we pre-agree for go/no-go and emergency rollback scenarios?

Learning, Ownership, and the Moment We Walk Away

• Is the organization prepared to operate this integration platform internally after project close, or will you want extended managed support? Options: Fully internal operation, Co-managed initially, Extended managed support required, Unsure
• How many people and what skill levels will you realistically dedicate to run and maintain the platform after handover? Options: 0–1 junior, 1–2 mid-level, 2+ senior engineers, Mixed levels, Unsure
• Which handover artifacts are non-negotiable for you (select all that must be delivered)? Options: Operational runbooks, Architecture diagrams, Source code and deployment scripts, Test suites and results, Access and credential documentation, Training materials / recordings
• What format of knowledge transfer works best for your teams (train-the-trainer, shadowing/co-delivery, recorded modules, documentation-only)? Options: Train-the-trainer, Shadowing / co-delivery, Recorded training modules, Documentation / runbooks only, Combination
• Are there internal certification or audit checkpoints we should prepare for as part of handover?

Decisions and Tradeoffs: Ready to Choose What Matters Most?

• Which tradeoff will you prioritize if forced to choose between speed, cost, and scope? Options: Prioritize speed (faster delivery), Prioritize cost (stay within budget), Prioritize scope/quality (full requirements), Balanced approach
• What would make you comfortable moving from discovery into a validated solution design (e.g., agreed success criteria, committed stakeholders, budget sign-off)?
• Who are the internal approvers we should plan to brief at the end of discovery, and what deliverable would they expect to review?
• If everything in discovery aligns, what is the earliest date you’d be ready to begin solution design activities? Options: Immediately, Within 2 weeks, Within 1 month, 1–3 months, Later than 3 months
• What remaining questions or concerns should we surface now so they don’t become blockers later?

• Current State & Consequence Alignment
• Transaction Scenario Workshop (Real Transactions & Failure Modes)
• Future-State Architecture Trace & Proof
• Failure-Mode Simulation & Acceptance Criteria Planning
• Validation Review & Go/Iterate Decision

• Customer to provision test environments, sanitized data sets, and SME availability for test windows.
• Obtain explicit stakeholder validation that the proposed future-state addresses the one-sentence problem and consequence metrics.
• Identify any architectural gaps and decide whether to iterate or proceed to define scope and responsibilities.
• Agree on a minimal PoC or simulation plan needed to prove remaining high-risk elements.
• Seller to update architecture diagrams and create a traceability matrix mapping architecture components to each diagnosed failure and consequence.
• Customer to confirm acceptance or list gaps with owners and timelines for remediation or follow-up analysis.
• Both parties to define the minimal PoC scope (if required) and schedule execution windows.
• Test Matrix Definition
• Finalize a detailed test matrix and acceptance criteria that prove the future-state for prioritized scenarios.
• Confirm environments, data, monitoring, and owners so simulations can be executed without ambiguity.
• Agree escalation and rollback decision authority for any test that risks production-like systems.
• Seller to produce the formal test matrix, runbook templates, and monitoring dashboards for each scenario.
• Introductions & Meeting Objectives
• Both parties to schedule dry-run dates and confirm sign-off authorities for test outcomes.
• Recap: Current State, Consequence, Future-State
• Obtain a clear go/no-go or prioritized iteration list with owners and deadlines for architectural validation.
• If go, agree the exact inputs and deliverables that will flow into the Solution Scope stage.
• Document residual risks and mitigation steps required before cutover planning begins.
• Seller to publish validated architecture package (diagrams, traceability matrix, PoC results, test matrix) into the shared workspace.
• Customer to confirm internal readiness and assign owners for items required in the Solution Scope stage (staffing, approvals, budgets).
• Both parties to schedule the Solution Scope kickoff and agree the timeline for remaining risk closures prior to that kickoff.
• Agree a single-sentence current state that the entire room endorses.
• Document concrete consequence metrics tied to business impact and operations (dollars, downtime, rework hours).
• Secure commitment on artifact delivery, SMEs, and dates needed for scenario validation.
• Customer to provide finalized one-sentence current-state and representative incident examples.
• Customer to deliver sample transaction payloads, error logs, and API/interface specs for prioritized systems.
• Customer and seller to confirm SME list and schedule for the Transaction Scenario Workshop.
• Scenario Selection & Priority
• Produce validated, prioritized transaction scenarios with full flow maps and failure-mode descriptions.
• Define concrete data quality thresholds and SLA expectations for each scenario to be used as acceptance criteria.
• Agree which scenarios will be simulated and the metrics that will prove/validate the future-state behavior.
• Seller to create canonical flow diagrams for each prioritized scenario including owners and touchpoints.
• Customer to provide sample datasets and redacted logs for each scenario and identify who will assist during simulations.
• Both parties to finalize scenario priority list and associated success metrics for the PoC/simulations.
• One-Sentence Future-State Statement
• Environment & Data Requirements
• Architecture Walkthrough Mapped to Scenarios
• End-to-End Flow Mapping
• One-Sentence Current-State Readout
• Simulation/PoC Results (or Planned Validation Summary)
• Monitoring, Observability & Success Signals
• Consequence Quantification
• Proof Patterns & Minimal Demonstrations
• Observed Failure Modes & Root Effects
• Decision: Validated, Needs Iteration, or More PoC
• Execution Plan & Roles
• Transition Next Steps into Solution Scope
• Data Quality & Business Rules
• Tieback to Consequence Reduction
• Artifact & SME Inventory
• Forced Validation & Feedback
• Scenario Prioritization for Simulation
• Risk & Contingency Controls
• Risk Register & Open Items
• Pre-work and Timeline

• Develop API adapters for legacy systems
• Deploy middleware platform and integration runtime
• Migrate master data to target ERP
• Implement real-time event streaming between applications
• Build ETL/ELT pipelines with data normalization
• Execute integration cutover and rollback operations
• Run integration performance and load testing
• Deploy monitoring, alerting, and operational runbooks
• Implement canonical data model and message schemas
• Build reusable integration templates and connectors
• Integrate cloud-to-on-prem via secure gateway
• Deliver operational knowledge transfer workshops

Develop API adapters for legacy systems

• How many distinct legacy systems require custom adapters? Options: 1, 2-3, 4-6, 7+
• Which interface types are used by these legacy systems? Options: SOAP/XML, REST/JSON, JDBC/ODBC, Flat files (FTP/SFTP), Message queue (MQ), Proprietary/Other
• Do legacy systems support modern authentication (OAuth2, JWT) or require credential-based access? Options: OAuth2/JWT, Basic Auth/API Key, Windows Integrated/NTLM, No auth / Anonymous, Other (describe)
• Are request/response APIs sufficient or do you need asynchronous/queued integrations for these systems? Options: Synchronous only, Asynchronous only, Both
• Estimate the average per-minute transaction volume for each legacy system (or describe ranges).
• What failure handling behavior is required for adapter errors (retry policy, DLQ, alerting)? Options: Immediate retry, Exponential retry, Dead-letter queue + alert, Log-only, Custom - describe
• Who will own ongoing maintenance of custom adapters after delivery? Options: Client internal team, Our team (managed service), Shared responsibility, TBD

Deploy middleware platform and integration runtime

• Which deployment model do you prefer for the middleware runtime? Options: On-premise, Cloud-hosted (vendor), Cloud self-managed (IaaS), Hybrid
• What scalability requirements should the runtime meet (peak TPS/latency SLAs)?
• Are there constraints on middleware vendors or required certifications (e.g., SAP PI/PO, Mulesoft, Boomi, Kafka Connect)? Options: Vendor locked (named), Vendor preference, Open to options, Must be open-source
• Do you require high-availability and cross-region failover? Options: Yes, No, Optional
• What runtime integration patterns are needed out of the box (API gateway, orchestration, ESB, messaging)? Options: API Gateway, Orchestration/Workflow, ESB, Event Bus/Messaging, File-based batch
• Do you need containerized deployment (Kubernetes) and CI/CD pipelines for runtime artifacts? Options: Yes, No, Unsure - discuss
• Who will provision and maintain runtime infrastructure (networking, SSL, certificates)? Options: Client infra team, Our operations team, Cloud provider managed, Shared

Migrate master data to target ERP

• Which master data domains are in scope (e.g., Customers, Vendors, Products, Chart of Accounts)? Options: Customers, Vendors, Products/Items, Chart of Accounts, Locations, Other
• How many master records per domain (approximate) will be migrated? Options: <10k, 10k-100k, 100k-1M, 1M+
• Is there an existing master data governance process or authoritative source? Options: Yes - designated source, Partial/Multiple sources, No formal governance
• Will data cleansing and de-duplication be performed by the client or require our services? Options: Client will handle, Require our data cleansing service, Shared responsibility
• Are there transformations, code mappings, or business rules to apply during migration? Options: Simple mappings, Complex transformations, Reference data mapping needed, None
• What acceptance criteria validate successful master data migration (record counts, duplicate rate threshold, data quality score)?
• Do regulatory or privacy constraints apply to master data movement (encryption at rest/in-transit, residency)? Options: Yes, No, Unknown - need review

Implement real-time event streaming between applications

• Which event platform(s) are preferred or already in use (Kafka, AWS Kinesis, Azure Event Hubs, RabbitMQ)? Options: Apache Kafka, AWS Kinesis, Azure Event Hubs, RabbitMQ, Other/None
• What categories of events need to be published (transactional, domain events, notifications, CDC)? Options: Transactional, Domain events, Notifications, Change Data Capture (CDC)
• What are the latency and delivery guarantees required (real-time <1s, near-real-time <5s, at-least-once, exactly-once)? Options: <1s, <5s, Seconds-minutes, At-least-once, Exactly-once
• Are schema registry and versioning practices required for events? Options: Yes - required, Optional, No
• Do consumers require replay/backfill of historical events? Options: Yes - full replay, Yes - limited window, No
• Who will own event topics, retention policies, and capacity planning? Options: Client team, Our team, Shared
• Is secure transport and encryption for streaming required due to PII or PCI data? Options: Yes, No, Unknown - need review

Build ETL/ELT pipelines with data normalization

• Which data sources must be included in pipelines (databases, APIs, files, SaaS)? Options: Databases, APIs, Flat files, SaaS connectors, Other
• Will pipelines run batch, micro-batch, or continuous ELT? Options: Batch (scheduled), Micro-batch, Continuous/Streaming
• Are there canonical normalization rules or mapping documents available? Options: Yes - documented, Partially documented, No - need discovery
• What data transformation complexity is expected (simple field mapping, enrichment, complex joins/aggregations)? Options: Simple mappings, Enrichment/lookups, Complex joins/aggregations, Machine-learning transforms
• Do pipelines require data lineage, auditing, and replayability for compliance? Options: Yes - full lineage, Basic auditing, No
• What target systems consume normalized data (data warehouse, ERP, analytics)? Options: Data warehouse/BI, ERP, Operational DB, Analytics platform, Other
• Who will operate CI/CD for data pipelines and manage schema changes? Options: Client team, Our team, Shared

Execute integration cutover and rollback operations

• What is the planned cutover window and allowable downtime? Options: Maintenance window (hours), Zero-downtime goal, Night/weekend window, Other
• Do you require staged/parallel run cutovers (coexistence of old and new integrations)? Options: Yes - parallel run, Direct cutover only, Phased by module
• What rollback triggers and acceptance criteria will mandate rollback during cutover?
• Are there transactional or referential integrity checks required immediately after cutover? Options: Yes - automated checks, Manual validation, None
• Who are the escalation contacts and decision-makers for rollback versus proceed decisions?
• Do you require rehearsed dry-runs and a rollback validation checklist prior to the live cutover? Options: Yes - mandatory, Optional, No
• Will external parties (third-party vendors, customers) be impacted and require notification/coordination? Options: Yes - notify/coordinate, No, TBD

Run integration performance and load testing

• What peak and sustained transaction volumes must be validated in testing?
• Do you require synthetic test data or can production-like data be anonymized for tests? Options: Synthetic test data, Anonymized production data, Combination
• Which performance metrics are required (latency p95/p99, throughput, error rate)? Options: Latency p95/p99, Throughput (TPS), Error rate, Resource utilization
• Should tests include end-to-end scenarios including downstream systems and batch jobs? Options: Yes - full E2E, Partial subset, No - isolated only
• Is a load-test environment with environment parity required, and who will provision it? Options: Yes - client to provision, Yes - our team to provision, No - use lower parity
• Do you require automated load-testing scripts and reporting for regression testing post-deployment? Options: Yes, No, Optional
• Are SLA thresholds defined that must be met during tests before go/no-go? Options: Yes - defined, Partial/Some defined, No SLAs defined

Deploy monitoring, alerting, and operational runbooks

• Which observability tools are required or already in use (Prometheus, Grafana, Datadog, Splunk)? Options: Prometheus/Grafana, Datadog, Splunk, Elastic Stack, Other/None
• What alerting thresholds and notification channels are required (email, Slack, PagerDuty)? Options: Email, Slack/MS Teams, PagerDuty, SMS, Other
• Do you need runbooks for specific failure modes (connectivity loss, backpressure, data drift)? Options: Yes - all listed, Only major failure modes, No
• Should runbooks include step-by-step remediation, rollback steps, and post-mortem templates? Options: Yes - full runbooks, High-level only, No
• Who will be the first responders and who will be responsible for triage and escalation? Options: Client on-call, Our operations, Shared rota
• Do you require synthetic monitoring and alerting for business KPIs (order flow, payment success)? Options: Yes, No, Partial
• Are retention and access policies for monitoring logs and metrics constrained by compliance? Options: Yes - constrained, No, Unknown - confirm

Implement canonical data model and message schemas

• Do you already have a canonical model or must one be designed? Options: Existing canonical model, Design required, Partial model exists
• Which domains should the canonical model cover initially (customers, orders, inventory, billing)? Options: Customers, Orders, Inventory, Billing/AR, Other
• Are schema registry and backward/forward compatibility policies required? Options: Yes - strict, Yes - flexible, No
• What serialization formats are preferred (JSON Schema, Avro, Protobuf, XML)? Options: JSON Schema, Avro, Protobuf, XML, Other

• Statement of Work (SOW)
• Master Services Agreement (MSA)
• Service Level Agreement (SLA)
• Commercial Terms & Payment Schedule
• Acceptance Criteria & Cutover Checklist
• Team Qualifications & Reference Verification
• Governance & RACI Charter
• Data Processing Agreement (DPA) & Security Addendum
• Change Control & Change Order Process
• Knowledge Transfer & Operational Handover Plan
• Post-Go-Live Support & Hypercare Agreement
• Risk Allocation, Insurance & Indemnity Confirmation
• Pilot/Reference Acceptance & Proof-of-Concept Sign-off

• Success Validation Review
• Operational Handover & Runbooks Walkthrough
• Lessons Learned & Continuous Improvement Retrospective
• Support, Monitoring & Escalation Alignment
• Enhancement Backlog & Roadmap Planning

• Schedule initial drill and periodic review cadence to validate the support model.
• One-sentence Successes & Frictions
• Capture explicit root causes and convert them into a prioritized improvement backlog.
• Agree on owners and timelines for quick wins and roadmap items to reduce future migration risk.
• Document lessons in a central repository for future projects and governance review.
• Publish a retro document with RCAs, proposed fixes, and prioritized backlog items.
• Assign owners and deadlines for quick-win fixes and schedule checkpoints.
• Add approved long-term improvements to the enterprise roadmap for funding/governance review.
• Support Model Overview
• Finalize support SLAs, monitoring thresholds, and escalation steps with named contacts.
• Operationalize the shared channel for incidents and enhancements with agreed governance.
• One-sentence Current State Recap
• Publish the support RACI, contact matrix, and on-call schedule to the shared operations portal.
• Configure monitoring alerts and ensure alert-to-ticket integration with assigned owners.
• Create the shared channel and seed it with templates for incident reports and enhancement requests.
• Collect & Categorize Enhancements
• Create a prioritized, time-boxed enhancement roadmap aligned to business impact and risk reduction.
• Assign owners and acceptance criteria for the top-priority items to ensure measurable delivery.
• Establish a governance path and communication cadence for ongoing backlog management.
• Publish the prioritized 90-day enhancement roadmap with owners, estimates, and acceptance criteria.
• Kick off the first enhancement sprint with defined scope, test plan, and validation steps tied to success signals.
• Set recurring roadmap review meetings and a single source-of-truth backlog in the shared channel.
• Confirm which success signals are met and which are outstanding, with evidence linked to each signal.
• Obtain formal acceptance, conditional acceptance with defined remediation, or rejection with an agreed remediation plan.
• Define owners, deadlines, and verification criteria for any outstanding remediation items.
• Publish a results matrix mapping each success signal to evidence and status (Met/Partially Met/Not Met).
• Create remediation tickets for outstanding items with owners, acceptance criteria, and verification date.
• Schedule a verification follow-up meeting to validate remediation outcomes.
• Handover Scope & Preconditions
• Ensure client operations team can execute normal and failure procedures from runbooks unassisted.
• Assign runbook owners and confirm access/credentials transfer plan.
• Schedule and commit to training/shadowing sessions and competency sign-offs.
• Deliver editable runbooks to the client's documentation repository and confirm receipt.
• Schedule a series of shadowing/training sessions and define criteria for competency sign-off.
• Create an access matrix listing required accounts, owners, and handover dates.
• Impact & Effort Assessment
• Monitoring Dashboards & Alert Thresholds
• Success Signals & Acceptance Criteria
• Runbook Walkthrough: Normal Operations
• Root Cause Analysis (select incidents)
• Measured Results Presentation
• Prioritization Workshop
• Process & Architecture Improvements
• Escalation Paths and RACI
• Runbook Walkthrough: Failures & Recovery
• Gap & Incident Review
• Access, Ownership, and Knowledge Transfer Plan
• Roadmap & Governance
• Shared Channel Governance
• Prioritize Improvement Backlog
• Communication & Delivery Cadence
• Decision: Accept, Conditional Accept, or Remediate
• Assign Quick Wins and Longer-term Initiatives
• Sign-off Criteria for Handover
• On-call & Drill Schedule
• Next Steps & Follow-ups