A quick operational snapshot

• How long has your current core processing platform been in production? Options: Less than 3 years, 3 to 7 years, 8 to 12 years, 13 to 20 years, More than 20 years
• Which core modules are actively used by your institution today, and which are rarely touched? Options: Deposit ledger, Loan servicing, Teller capture, ACH/Wire origination, Regulatory reporting, Other (please specify)
• Approximately how many active customer accounts and active loan files will require migration? Options: Under 50,000 accounts, 50,000 to 250,000 accounts, 250,000 to 1M accounts, Over 1M accounts
• Who on your team currently owns the relationship with the incumbent core vendor and the day to day runbook?
• Do you have a documented disaster recovery or conversion runbook that was executed or tested in the last three years? Options: Yes, executed in last 12 months, Yes, executed 12 to 36 months ago, Document exists but not executed, No documented runbook

If a single outage could top your risk appetite

• What single operational failure during a conversion would force your board to halt the project immediately? Options: Branch teller freeze longer than 2 hours, Regulatory reporting gaps for a filing period, Major ACH or wire settlement errors, Core accounting parity breach over X customers, Other (explain)
• How often have you experienced account balance discrepancies after system changes in the last two years? Options: Never, Once, A few times, Monthly or more
• Walk me through the last time a software update affected teller operations, what happened, and how long it took to recover.
• Which downstream functions suffer first when accounting parity is off and who notices it first? Options: Branch operations, General ledger reconciliation, Customer service/disputes, Third-party integrations, Regulatory reporting
• Estimate the financial exposure per hour for a branch outage during business hours, including lost deposits and remediation costs. Options: Under $5,000, $5,000 to $25,000, $25,000 to $100,000, Over $100,000

What the board and regulator will ask for

• If the regulator asked for evidence that conversion will not interrupt reporting, what single proof would you expect to produce? Options: Parallel-processing pilot report, Audited reconciliation package, Third-party attestation, Rollback and contingency plan, Other (please specify)
• Identify the executive and board members who must sign off on conversion risk documentation before a final vote.
• List the formal regulatory triggers that would require you to pause or alter a cutover window. Options: Open examiner actions, Pending mergers or acquisitions, Significant financial stress indicators, Material customer complaints, Other (explain)
• In prior exams, what penalties or findings have been issued for gaps in disaster recovery or conversion procedures at your institution?
• What internal evidence or historical reports do you already have that demonstrate uptime or no-impact during past system changes? Options: Reconciliation reports, Incident logs with timelines, Third-party audit reports, No documented evidence

Where conversion projects usually stall in your organization

• Name the part of migration planning that has derailed projects in your experience: data, integrations, people, or governance. Options: Data conversion, Third-party integrations, Staff capacity and training, Executive governance and approvals, Other (explain)
• Provide the headcount you can realistically dedicate to a parallel-processing pilot from day one, and list their roles. Options: 0-2 FTEs, 3-5 FTEs, 6-10 FTEs, More than 10 FTEs
• Identify the named owners and backups who will be responsible for conversion decisions and approvals.
• Describe the data sets that are likely to require the most cleansing before migration and why.
• If integration endpoints lack clear APIs or documentation, what fallback approach would you accept and who owns that decision? Options: Batch file exports with checksums, Custom adaptor development, Delay onboarding that integration, Replace the third party, Other (explain)

The other options on your table

• List the alternatives you are actively considering right now, including staying with the incumbent, replacing modules, or solving internally. Options: Remain on incumbent core, Replace entire core, Replace modules only, Internal rebuild, Other vendor
• Name any internal advocates for an in-house rebuild and what resources they claim are available.
• Identify the specific vendor capabilities that would have to be demonstrably present for you to pick them over your current provider. Options: Proven conversion uptime, Parallel-processing methodology, Regulatory reporting continuity, Clear third-party integration plan, Transparent TCO modeling
• Describe the conditions that would have to be true for you to stay on your current platform for the next five years.
• Would a credible no-downtime, audited migration plan from your incumbent plus a contractual uptime guarantee be sufficient to stop this search? Options: Yes, would stop search, Maybe, depends on terms, No, not sufficient

Acceptance criteria that will make the contract signable

• Imagine the parallel-processing pilot proves accounting parity and uptime, what remaining approvals or blockers would still prevent a near-term signature?
• Specify the measurable acceptance criteria you require for account balance parity, uptime, and regulatory reporting completeness. Options: Account balances match within 0.01%, Uptime 99.9% or higher, No missing regulator submissions, Transaction parity within agreed tolerance, Other (specify)
• Specify the roles that will provide final sign-off to move from pilot to commercial commitment and the evidence each role requires.
• State the maximum increase in total cost of ownership over a seven year horizon you would accept to complete the conversion. Options: No increase accepted, Up to 5% increase, 5% to 15% increase, More than 15% increase
• Provide the earliest realistic board approval window if the pilot meets your acceptance criteria. Options: Immediate (within 2 weeks), 2 to 4 weeks, 1 to 2 months, Longer than 2 months

Operational readiness and critical constraints

• Tell us which third-party systems must be connected for full operations and whether APIs or file transfers are available today. Options: Internet banking platform, ATM processor, Payment networks (ACH/wire), Treasury/GL systems, Fraud/AML providers, Other (specify)
• Enumerate the key data sources, their owners, and whether export access exists today.
• Rate the maturity of your internal data dictionaries and field-level documentation on a 1 to 5 scale. Options: 1 - Poor, 2 - Low, 3 - Moderate, 4 - High, 5 - Excellent
• Report any third-party integrations that carry contractual restrictions which could prevent parallel processing or cutover sequencing. Options: No restrictions, Requires vendor consent, Requires contract amendment, Unknown, need review
• Would an inability to export required migration data within 90 days stop the project? Options: Yes, would stop project, No, we have workaround, It would delay timeline but not stop

User adoption, training, and operational support

• Explain which post-live SLA or support commitment would change your buying decision today. Options: Guaranteed conversion uptime, Dedicated conversion support team, Financial penalties for missed SLAs, Extended warranty on integrations, Other (specify)
• Share the top three operational KPIs you will track in the first 12 months after go-live.
• Estimate the number of staff hours per week your operations team will need to support the new platform after cutover. Options: Under 20 hours, 20 to 50 hours, 50 to 100 hours, Over 100 hours
• Select your preferred training model for branch and back office staff. Options: Train the trainer on-site, Remote instructor led, Self-paced modules with assessments, Blended approach
• Map the roles and escalation order for major incidents and indicate whether contact information is already available.
• Answer whether a vendor commitment to 99.9 percent uptime during conversion with financial penalties would be sufficient to proceed. Options: Yes, sufficient, Maybe, subject to audit, No, not sufficient

Next steps, timing, and the single deal accelerator

• State the earliest cutover window your board would consider acceptable given regulator cycles and reporting periods. Options: Within 3 months, 3 to 6 months, 6 to 12 months, 12 to 18 months
• Select your target go-live window timeframe. Options: Pilot only, no fixed go-live, 3 to 6 months after pilot, 6 to 12 months after pilot, 12+ months after pilot
• Indicate any statutory or board blackout periods that would prevent cutover, such as fiscal year end or pending audits.
• Outline the procurement and legal steps that remain and provide typical durations for each.
• Point to the single remaining blocker that would prevent signature within 30 days even after a successful pilot. Options: Board approval, Regulatory clearance, Legal/contract terms, Budget / CFO approval, Other (specify)

• Conversion Assurance Experience Session

• Confirm the current state and its cost to your team
• You confirm the demonstrated flow prevents teller-line outages and eliminates the freeze risk you described.
• Provide three high-risk account and integration scenarios plus two weeks of sample transaction extracts for sandbox validation.
• Run your high-risk teller-day scenario end to end
• You confirm regulator reporting runs end to end during conversion with no gaps for the demonstrated scenario.
• Run the provided scenarios in the sandbox and deliver a conversion parity report that includes reconciliation logs, exception lists, and a simulated uptime summary before the pilot kickoff.
• Demonstrate regulatory reporting continuity using a recent filing scenario
• Share a draft parallel-processing pilot acceptance criteria template populated with the session's agreed metrics.
• You agree on the specific evidence and acceptance criteria required to proceed to the parallel-processing pilot.
• Confirm planned cutover windows and named regulator contacts for notification and reporting during the pilot.
• Show conversion safeguards and verification checks
• Validate this maps to your requirements
• Agree next evidence and pilot acceptance items

• Conversion Assurance Experience Session
• Conversion Assurance Deck
• Conversion Assurance Brief

• meeting
• slides
• document

• Migrate Deposits Ledger and Balances
• Migrate Loan Portfolio and Servicing Records
• Migrate Transaction History and Teller Capture
• Provision Hosted Core Environment
• Configure Real-Time Posting and Balancing
• Activate ACH and Wire Origination Engines
• Deploy Reg E Dispute Workflows
• Enable Automated CTR and Regulatory Filings
• Integrate Third-Party Digital Channels and Vendors
• Establish Parallel Processing Environment
• Run Data Reconciliation and Exception Resolution
• Train Staff on New Workflows and Teller Operations
• Execute Cutover Weekend Conversion
• Provide 24/7 Conversion Uptime Monitoring and SLA Reporting

Migrate Deposits Ledger and Balances

• How many deposit accounts exist in your current ledger broken out by product (checking, savings, money market)? Options: Less than 5,000, 5,000-50,000, 50,000+
• Which balance as-of date must be preserved for regulatory reconciliation (for example, available balance at 23:59 on the migration snapshot date)?
• Specify the chart of accounts and general ledger (GL) code mappings that tie deposit products to your GL for migration mapping.
• Are there deposit hold rules or availability schedules (for example, check hold buckets, incoming ACH hold rules) that require special transformation? Options: Yes, No
• Identify MICR normalization, account number formatting, and check-image linkages that must be preserved for teller history.
• What acceptance criteria will confirm deposit balances migrated correctly (for example, per-account variance threshold, aggregate trial balance match, and a defined sample of top 1,000 depositors with zero variance)?

Migrate Loan Portfolio and Servicing Records

• How many active loan accounts must migrate, broken out by loan type (consumer, mortgage, commercial)? Options: Less than 1,000, 1,000-10,000, 10,000+
• Provide the servicing attributes that must migrate (next due date, unpaid principal balance, interest rate index, escrow balances).
• Specify the file formats for loan schedules and payment histories (for example, CSV amortization export, XML payoff files, fixed-width extracts).
• Are escrow, subordinate liens, or tax/insurance subaccounts tied to loans that require separate ledger migration? Options: Yes, No
• Who will own validation of promissory note references and loan ID reconciliation during the parallel pilot? Options: You, We, Shared responsibility
• Which loan transaction history window is required for servicing parity (for example, last 12 months, last 36 months, full-term)? Options: Last 12 months, Last 36 months, Full term, Custom

Migrate Transaction History and Teller Capture

• Estimate the total transaction row count for teller captures and system transactions to be migrated. Options: Less than 1M, 1M-10M, 10M+
• List the check image linkage requirements and whether full image binaries or pointers must be migrated for teller-presented items.
• State the branch cutoff time that defines same-day posting for teller transactions during migration windows. Options: End-of-day batch, Branch cutoff time (for example, 4:00 PM), Other
• Specify transaction retention periods that the new platform must meet for audits and regulator requests (for example, 7 years, 10 years). Options: 7 years, 10 years, Custom
• Are teller override and manager-approval flags required to preserve original audit trails for transactions? Options: Yes, No
• Identify the current transaction export formats (for example, fixed-width ACH extracts, CSV, ISO 20022) and any transformations required.

Provision Hosted Core Environment

• Which production-equivalent environment profile do you require for hosted core capacity planning (for example, CPU, memory, and IOPS categories)? Options: Small, Medium, Large, Custom sizing required
• Specify your expected monthly transaction volume and peak daily throughput to size the environment accurately.
• Which examiner or regulator requirements must the hosted environment meet for evidence (for example, FDIC, NCUA examiner artifacts, encryption audit trail)?
• Do you require a dedicated single-tenant environment or a logically partitioned multi-tenant instance for your data? Options: Dedicated single-tenant, Partitioned multi-tenant
• Specify the encryption-at-rest and key management standard required (for example, FIPS 140-2 compliant keys, customer-managed keys). Options: FIPS 140-2, Organization-managed keys, Customer-managed keys, Other
• How will you verify hosted core readiness before the first data import (for example, smoke-test uptime threshold, connectivity to branch endpoints, sample end-to-end transaction)?

Configure Real-Time Posting and Balancing

• Which posting rules define real-time versus batch posting in your current operations (for example, teller cash posts real-time, interest posts nightly)?
• Specify inter-day balancing thresholds and auto-adjust exception limits that must be enforced after cutover.
• How will your existing end-of-day balancing reports be migrated (report name, format, and reconciliation logic)?
• Are there custom cent-level rounding rules or interest posting behaviors that must be preserved to match regulatory reports? Options: Yes, No
• Who will own resolution of posting and balancing exceptions during the pilot phase? Options: You, We, Shared responsibility
• Indicate the maximum allowable posting latency during peak hours for real-time posting (for example, <100 ms, 100-500 ms). Options: <100 ms, 100-500 ms, 500 ms - 2 s, >2 s

Activate ACH and Wire Origination Engines

• Which ACH originator IDs and routing relationships must be configured and cut over on day one?
• Specify the ACH file formats and NACHA layout variations you currently use that must be supported.
• Are same-day ACH and wire cutoff times aligned with your current operations and do they require change? Options: Yes, No
• List correspondent banks, payment hubs, or gateway providers that must be reconnected for wires and ACH.
• Which OFAC screening cadence do you require during conversion and after go-live (for example, real-time screening or nightly batch)? Options: Real-time, Batch, Hybrid
• Will you require preservation of sender remittance and beneficiary remittance field mappings for reconciliation? Options: Yes, No

Deploy Reg E Dispute Workflows

• How many active Reg E dispute cases and historic records must migrate into the new dispute queue? Options: None, <100, 100-500, 500+
• Specify the dispute lifecycle steps you require mapped to workflow states (for example, initial notice, investigation, provisional credit, closure).
• Are there custom dispute reason codes, narrative templates, or correspondence templates that must be retained? Options: Yes, No
• Who will be the named owner for dispute case validation and final sign-off during the pilot? Options: You, We, Shared responsibility
• Which audit trail fields are required for examiner evidence (for example, investigator ID, timestamps, closure code)?
• Indicate the allowable SLA for provisional credit processing during conversion (for example, 24 hours, 48 hours). Options: 24 hours, 48 hours, Custom

Enable Automated CTR and Regulatory Filings

• Which Currency Transaction Report (CTR) filing thresholds and jurisdiction rules do you currently use and must preserve?
• Specify the current automated filing cadence and the regulator or filing agent endpoints we must submit to (for example, secure API, SFTP).
• Are SAR referral processes integrated with your existing AML tooling and must those integrations remain in scope? Options: Yes, No
• Which filing file formats and test endpoints does your regulator or filing agent require (for example, XML schema, FTP, secure API)?
• Who will validate regulator transmission receipts and retain evidence for examiner review? Options: You, We, Shared responsibility
• What acceptance evidence will confirm regulatory filings operate correctly during pilot (for example, sample transmitted filings with regulator acknowledgements, automated transmission receipts)?

Integrate Third-Party Digital Channels and Vendors

• Which digital channels must be live at cutover (for example, online banking API, mobile banking, ATM switch)? Options: Online banking API, Mobile banking, ATM switch, Bill pay, Other
• Specify integration endpoints and authentication methods for each vendor (for example, API key, OAuth 2.0, SFTP) that must be configured.
• Are there third-party vendor contracts that require coordination for your chosen cutover window? Options: Yes, No
• Which API schemas or message formats must be supported for transaction posting from channels (for example, REST JSON, SOAP XML, switch ISO messages)?
• Who will execute end-to-end vendor testing for channel transactions during the parallel pilot? Options: You, We, Shared responsibility
• Identify any vendor-supplied middleware, adapters, or gateway appliances that must be certified before go-live.

Establish Parallel Processing Environment

• Which account sets and transaction types will be included in the parallel-processing pilot (for example, a single branch, business accounts, high-risk account subset)?
• Specify the pilot duration and daily processing window for parallel runs (for example, number of days and business hours each day).
• Are daily reconciliation cutoffs required between the source core and target core during the pilot? Options: Yes, No
• Which tooling will capture parity metrics and diffs (for example, per-account trial balance reports, transaction diff logs)?
• Who will perform daily parity review and sign-offs during the pilot period? Options: You, We, Shared responsibility
• Indicate any exclusions from the pilot such as newly opened accounts, frozen accounts, or suspended ACH origins.

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

• Master Services Agreement (MSA)
• Order Form / Subscription Agreement
• Statement of Work (SOW)
• Service Level Agreement (SLA)
• Cutover Responsibilities & Acceptance Plan
• Data Processing & Regulatory Compliance Addendum
• Conversion Fidelity Warranty & Remediation Agreement
• Change Order Agreement
• Transition & Termination Assistance Agreement

• Go-live Health Check (weeks 1-4)
• First Measurement Review (weeks 4-10)
• 90-Day Realization Review
• Quarterly Operational Review (ongoing quarterly)

• Schedule monthly office hours focused on operational training and integration troubleshooting for the next quarter.
• Schedule focused operational retraining sessions addressing the top 3 user errors identified in the first 30 days.
• Status vs Go‑Live Validation criteria
• Confirm the status of each Go‑Live Validation acceptance criterion and document remediation plans for any items not yet closed.
• Validate that the incumbent system has been decommissioned or retained read-only and that data archival or migration is complete.
• Agree the operating support model, SLAs, and escalation path for steady-state operations.
• Publish a closure plan for any remaining Go‑Live Validation criteria with specific evidence required and target dates.
• Complete the incumbent system decommission or read-only retention steps and provide the archival certificate or retention plan.
• Deliver the regulator reporting audit trail for the first 90 days and any corrective filings made.
• Quarterly operational scorecard
• Confirm the platform met or is on track to meet the uptime and operational targets recorded in Go‑Live Validation.
• Reduce the open enhancement backlog by agreeing the top items and target delivery quarters.
• Define preventive actions for recurring incidents and commit to measurable verification steps for the next review.
• Publish the quarterly operational scorecard including uptime, reconciliation parity, regulator exceptions, and ticket backlog.
• Prioritize the top five enhancement requests with acceptance criteria and target delivery quarters.
• Re-confirm success criteria and owners
• Confirm the deployment completed to the checklist in Go‑Live Validation and that named owners understand outstanding work.
• Identify any Severity 1 or 2 issues and agree remediation windows and verification steps.
• Agree the next deliverables to demonstrate early stability before the first measurement meeting.
• Deliver reconciled account parity summary for the top impacted accounts and the reconciliation method used.
• Provide integration success/failure log for the cutover window and the last 48 hours of production activity.
• Publish remediation plan for all open Severity 1/2 hypercare tickets with target close dates.
• Present first-period metrics
• Determine whether reconciliation parity and production uptime are trending to the targets recorded in Go‑Live Validation and identify any blockers.
• Agree a prioritized remediation list with measurable acceptance criteria and target dates to close gaps.
• Confirm the next data delivery and verification steps needed for the 90-day realization review.
• Produce root-cause analysis for reconciliation exceptions exceeding tolerance and propose concrete fixes.
• Deliver a one-week uptime and incident timeline for the period showing any outage windows and causes.
• Data fidelity and regulator reporting review
• Third-party integration health
• Deployment and migration validation
• Root cause diagnosis for gaps
• Incumbent system wind-down checkpoint
• Early adoption signals and user onboarding
• Enhancement and backlog review
• Agree corrective actions and timelines
• Open issues and immediate remediation actions
• Confirm timeline to stabilization
• Persistent incidents and preventive actions
• Prioritize remaining defects and timeboxed remediation
• Agree follow-up checkpoints
• Confirm post-live support channel and escalation path
• Confirm next quarter support checkpoints