Payment platform migration moves live traffic, stored credentials, and billing records from one payment provider to another across five phases: discovery, dual-run architecture, execution, cutover with hypercare, and normalization. Compressing the dual-run phase removes the fallback, so token mismapping and authorization-rate drops surface only after real cardholders have been charged.
A payment platform migration succeeds or fails on four architecture decisions locked before the cutover date: big-bang versus dual-run strategy, the token or PAN transfer mechanism, parallel-run duration, and the rollback trigger. The data export is rarely what breaks when a PSP, issuer processor, or billing system changes hands; most failed migrations trace to one of those four decisions being made too late.
Organizations replacing a provider assume the transition will follow standard scheduling and data-export procedures. They expect the destination vendor to handle the mechanical execution and manage the underlying complexity.
The decisions that determine the outcome are made weeks before the cutover date, inside architecture. The destination vendor sells the platform and makes none of those four decisions, so understanding how fintech companies build payment platforms tells you where your traffic is actually landing.
Silent token mismapping, authorization rate drop, and the point of no return are all consequences of poorly managed migration of a payment platform. This article addresses the decisions to be made during migration planning, the five stages and their corresponding risks, timelines, and costs depending on complexity level, and the differences between switching your PSP, migrating your issuer processor, migrating your billing platform, and upgrading to ISO 20022 messaging.
Why Payment Platform Migration Is an Architecture Decision, Not a Data Export
Migrations that go badly rarely do so due to a lack of effort. They go badly because four architectural questions were answered late, by default, or by the destination vendor: the migration strategy, the mechanism for moving tokens or PANs, the length of the parallel run, and the rollback trigger.
Timelines, matrices, and communications plans are left unaffected in all four cases. The failures that occurred were design issues that were already fixed when the project plan was being developed: silent token mismapping, authorization rate drop, and go-live without any rollback option.
Onboarding time at Blackhawk Network fell from seven days per merchant to under 24 hours, with 8,000+ US businesses processed over two years. That came from a self-service registration portal we delivered that automated OFAC, EIN, and SSN verification checks and integrated Salesforce lead automation. Running the seven-day process more carefully would never have produced it; the flow itself had to change.
Choosing a Migration Strategy: Big-Bang vs. Phased vs. Dual-Run
Strategy gets constrained before it gets chosen. A merchant with stored credentials and recurring charges running through a single direct gateway integration has fewer options than one already routing through an abstraction layer, and payment gateway vs. payment orchestration is the distinction that determines which of the three approaches below is genuinely available.
Strategy | What It Is | Primary Risk |
|---|---|---|
Big-bang cutover | All traffic moves to the new platform at a single defined moment; the old platform is switched off immediately after | No fallback if something breaks post-cutover: every issue becomes a live production incident handled under load, with no rollback path available once the old platform is off |
Phased / wave-based | Traffic or accounts move in defined batches (by entity, product line, or customer segment) over weeks | Requires both platforms to stay reconcilable and compliant simultaneously for the duration of the waves |
Parallel / dual-run | Both platforms process live traffic simultaneously for a defined window while data and behavior are validated before full cutover | Highest short-term operational overhead: two systems, two sets of monitoring, two compliance surfaces, and two sets of reconciliation output to keep in agreement |
Strategy
Big-bang cutover
Phased / wave-based
Parallel / dual-run
What It Is
All traffic moves to the new platform at a single defined moment; the old platform is switched off immediately after
Traffic or accounts move in defined batches (by entity, product line, or customer segment) over weeks
Both platforms process live traffic simultaneously for a defined window while data and behavior are validated before full cutover
Primary Risk
No fallback if something breaks post-cutover: every issue becomes a live production incident handled under load, with no rollback path available once the old platform is off
Requires both platforms to stay reconcilable and compliant simultaneously for the duration of the waves
Highest short-term operational overhead: two systems, two sets of monitoring, two compliance surfaces, and two sets of reconciliation output to keep in agreement
Dual-run is the default for any business with recurring billing or stored payment credentials because it is the only strategy that lets you compare platform behavior on live traffic before committing to it. Big-bang is defensible for genuinely simple, low-volume, and non-recurring setups: a virtual terminal, a single hosted checkout, no credentials on file.
The Technical Playbook: Five Phases of a Payment Platform Migration
Each phase below ends where a go/no-go gate should sit: a point at which the program either has what it needs to proceed or stops and says so. Treating those gates as real decisions is what separates a program that runs on schedule from one that discovers its problems in production, in front of cardholders.
Phase 1: Discovery and Data Mapping
Before any build work begins, the inventory must be complete:
- stored tokens and PANs
- active subscriptions and their renewal dates
- every webhook consumer
- fee and interest structures
- connected CRM, fraud, and reporting integrations that read from the current platform.
Fee logic and interest accrual rules are frequently undocumented and live only in the outgoing provider’s configuration screens.
Eight separate eCommerce platforms, acquired by Blackhawk Network, each carried its own data model. The consolidation we ran folded all eight platforms into one system of 80+ services, moved data representing $30B in annual load value, and added a BI layer handling 40M+ records per day across 100+ report types — scope defined during discovery, not discovered during execution.
Incomplete mapping of recurring-billing dependencies is the most common root cause of failed migrations. Teams skip it and find the gap when a renewal cycle fails weeks after cutover, well outside the testing window.
Phase 2: Architecture and Dual-Run Design
The new integration is built against the sandbox while the old one continues to process live traffic: API contracts, webhook consumers, idempotency handling, and reconciliation hooks are all designed before a single record moves. The decision that shapes everything downstream is how stored credentials travel — scheme-approved token transfer between processors or asking cardholders to re-enter their card details.
Token-only migration of a subscription business without building a dual run is a mistake made due to an early architectural decision, but it is experienced later as a data issue.
Poynt, a US payments and commerce platform, ran its reseller portal within a monolithic system where every change was expensive and tightly coupled to everything else. A dedicated eight-person SPD Technology’s team took full ownership across a two-year engagement and decoupled the portal from the monolith, reducing ongoing dependencies and the support resources the platform required.
Phase 3: Migration Execution
The execution process comes before any transfer of active credentials. The token and PAN migration will be performed in the destination platform’s staging environment to validate record counts, field mapping, and reconciliation results without risking the cost of errors.
The actual data is then transferred in live waves, using end-to-end encryption. PGP over SFTP remains the standard method for transferring credential files between processors operating under PCI DSS, and the rest of the payment security architecture will determine who owns the keys, the decryption process, and file retention periods at both ends.
Rehearsal matters more as volume climbs. A US document-management provider with 30+ years in business and Fortune 500 clients needed to move its legacy platform to the cloud. Our team executed a 20 TB legacy-to-cloud migration and rebuilt the system on a multi-tenant architecture with complex role management, sharply reducing file download times.
Linking data back together concludes every transferred wave. A migrated credential must map correctly to its corresponding customer. The same rule applies to the ledger record and to any linked subscription from the previous system. Flaws in token re-association happen quietly. You will rarely see migration errors trigger alerts for mismapped tokens. These issues usually stay hidden for weeks until an incorrect record gets billed during a live card charge.
Oleksandr Boiko
Delivery Director at SPD Technology
“Token re-association is the one migration step that succeeds silently and fails silently. The file transfers, the record counts match, and the reconciliation report comes back clean — then the error surfaces weeks later, on a live cardholder’s next scheduled charge. We reconcile every migrated token against its original record before go-live, because after go-live the feedback loop runs through your customers.”
Phase 4: Cutover and Hypercare
Go-live becomes the most heavily instrumented phase of the migration effort. Hypercare involves having a dedicated rapid-response team available, with alert thresholds set well below what is considered normal, and an overriding focus on a single metric — the authorization rate of the new platform relative to the old.
Authorization rates drop predictably after cutover. The issuers and network learn the new merchant ID or BIN; the fraud model has to re-establish what’s normal for this new descriptor; stand-in processing works differently against a brand-new profile. Teams that have budgeted for the drop plan to take it during a very low-volume window; teams that have not budgeted take it during a high-volume window.
Phase 5: Post-Migration Normalization
There are three objectives to accomplish in the first few weeks post go-live: observing the recovery of the authorization rate to baseline levels, wrapping up the parallel run phase, and finally dismantling the old environment. The recovery process can be measured; any authorization rate below baseline in the weeks following the event cannot be attributed to a lack of familiarity among issuers and must mean a misconfiguration.
Decommissioning before the close of the parallel-run period eliminates the fallback necessary for disputes, chargebacks, and audits that can occur only after the go-live. Most seasoned teams keep at least 90-180 days. Early termination of the contract comes down to a direct cost-versus-risk equation, and the risk should always win until the dispute window has closed.
Migration Risk Flags: What Actually Goes Wrong
All the following items have caused a migration failure at least once because they fell outside the window. In three cases, they involve direct audit implications and thereby place payment gateway compliance and security in the migration itself, before anything else after go-live.
Risk Flag | Why It's Missed | What Prevents It |
|---|---|---|
Incomplete recurring-billing data mapping | Discovery focuses on static account data and overlooks renewal-cycle dependencies | Explicit subscription and renewal audit as a distinct discovery task, not a subset of general data mapping |
Token-only migration path chosen too early | The token vs. dual-run decision gets made as a vendor default, not an explicit architecture call | Decide the transfer mechanism against the business’s actual card-on-file dependency, not the new vendor’s default flow |
Silent token/PAN re-association errors | Mismapped tokens throw no error at migration time — they surface on the next charge attempt, once the record is live | Reconciliation pass matching every migrated token against its original record before go-live |
Authorization-rate collapse post-cutover | Teams treat go-live as the finish line rather than the start of a recovery period that has to be monitored | Budget a defined normalization window, cut over during low-volume periods, and monitor auth rate as the primary go-live metric |
No defined rollback trigger | Rollback gets discussed as a concept but is never tied to a specific, measurable condition before cutover | Write the exact rollback trigger into the go-live plan before cutover, with its metric, threshold, and observation window agreed upon while nothing is on fire |
Old platform decommissioned too early | Cost pressure to end the old contract collides with the need for a dispute and audit fallback window | Hold both platforms live for a defined parallel-run window, commonly 90–180 days, before full decommissioning |
Risk Flag
Incomplete recurring-billing data mapping
Token-only migration path chosen too early
Silent token/PAN re-association errors
Authorization-rate collapse post-cutover
No defined rollback trigger
Old platform decommissioned too early
Why It's Missed
Discovery focuses on static account data and overlooks renewal-cycle dependencies
The token vs. dual-run decision gets made as a vendor default, not an explicit architecture call
Mismapped tokens throw no error at migration time — they surface on the next charge attempt, once the record is live
Teams treat go-live as the finish line rather than the start of a recovery period that has to be monitored
Rollback gets discussed as a concept but is never tied to a specific, measurable condition before cutover
Cost pressure to end the old contract collides with the need for a dispute and audit fallback window
What Prevents It
Explicit subscription and renewal audit as a distinct discovery task, not a subset of general data mapping
Decide the transfer mechanism against the business’s actual card-on-file dependency, not the new vendor’s default flow
Reconciliation pass matching every migrated token against its original record before go-live
Budget a defined normalization window, cut over during low-volume periods, and monitor auth rate as the primary go-live metric
Write the exact rollback trigger into the go-live plan before cutover, with its metric, threshold, and observation window agreed upon while nothing is on fire
Hold both platforms live for a defined parallel-run window, commonly 90–180 days, before full decommissioning
Migration Timeline and Effort by Complexity Tier
The ranges below assume a team that has done this before and a discovery phase that finished properly. An issuer processor migration and a PSP migration can occupy the same calendar month and share almost nothing else in engineering terms.
Complexity | Example Scenario | Typical Timeline |
|---|---|---|
Minimal | Virtual terminal setup, no stored tokens, no recurring billing | Under 1 day to 1 week |
Standard | E-commerce PSP switch with stored card tokens and moderate transaction volume, moving on a single acquiring relationship | 4–12 weeks |
Complex | Issuer-processor or full card-portfolio migration with stored PANs at scale, including ledger and interest configuration parity | 3–7 months |
Regulated / multi-entity | Multi-market card program or treasury messaging migration like ISO 20022 with compliance dependencies | 6–12+ months |
Complexity
Minimal
Standard
Complex
Regulated / multi-entity
Example Scenario
Virtual terminal setup, no stored tokens, no recurring billing
E-commerce PSP switch with stored card tokens and moderate transaction volume, moving on a single acquiring relationship
Issuer-processor or full card-portfolio migration with stored PANs at scale, including ledger and interest configuration parity
Multi-market card program or treasury messaging migration like ISO 20022 with compliance dependencies
Typical Timeline
Under 1 day to 1 week
4–12 weeks
3–7 months
6–12+ months
Discovery is the phase that gets underestimated, and from the regulated side, the explanation is clear from publicly available programs: the Federal Reserve migrated the Fedwire Funds Service to the ISO 20022 message format in July 2025, for a service that handles more than $4.7 trillion in wire transfers on average per day, not something that gets shipped in quarterly release cycles.
Ledger and reporting parity drives the complex tier further than transaction volume does — the settlement platform SPD Technology built for Blackhawk Network now serves 37,000+ users with automated report generation and commission calculation, out of a partnership that began with NimbleCommerce in 2008 and has run in its current form for 7+ years.
What Payment Platform Migration Actually Costs
Cost here refers to the categories that fall under the program budget based on different weights according to complexity level and parallel-run time. In most cases, when teams reach this stage, they have already weighed build vs. buy payment gateway economics and discovered that migration is cheaper than building but more expensive than the switch the destination vendor claims in its onboarding slides.
Cost Category | What It Covers |
|---|---|
Exit costs from the old provider | Export fees, early-contract-termination fees, and any data-transfer fees the outgoing provider charges, plus the cost of holding the old contract open through the parallel-run window |
Setup and migration fees from the new provider | Onboarding, underwriting, and any migration-specific fees the destination platform charges |
Engineering time — dual-run build and testing | Building and testing the new integration in parallel with the live old one, before any traffic moves, including rehearsal runs against a staging copy |
Parallel-run operational overhead | The cost of running, monitoring, and reconciling two platforms simultaneously during the dual-run window |
Contingency / rollback buffer | Budget and engineering time held in reserve specifically for executing a rollback if the go-live trigger condition is met |
Cost Category
Exit costs from the old provider
Setup and migration fees from the new provider
Engineering time — dual-run build and testing
Parallel-run operational overhead
Contingency / rollback buffer
What It Covers
Export fees, early-contract-termination fees, and any data-transfer fees the outgoing provider charges, plus the cost of holding the old contract open through the parallel-run window
Onboarding, underwriting, and any migration-specific fees the destination platform charges
Building and testing the new integration in parallel with the live old one, before any traffic moves, including rehearsal runs against a staging copy
The cost of running, monitoring, and reconciling two platforms simultaneously during the dual-run window
Budget and engineering time held in reserve specifically for executing a rollback if the go-live trigger condition is met
Migration Type Comparison: PSP, Issuer-Processor, Billing, and Messaging Migrations
The four types below share a playbook and diverge sharply on what actually breaks. Teams already running payment orchestration platforms absorb the first type as routing configuration and still meet the other three at full weight. The first row is what most teams mean by a payment gateway migration — checkout, tokens, and webhooks moving together, which is standard scope in merchant payment gateway development work.
Migration Type | What Moves | Primary Technical Risk |
|---|---|---|
PSP / gateway switch | Stored card tokens, checkout integration, webhook handling, and the reporting feeds reading off both | Token re-association and authorization-rate normalization with the new acquiring relationship |
Issuer-processor / card portfolio migration | Cardholder profiles, PANs, ledger and interest configuration, scheme integrations | PAN transfer at scale under scheme-approved processes, plus ledger and product configuration parity |
Billing / subscription platform migration | Subscription records, renewal cycles, dunning, and invoicing logic | Renewal-cycle timing errors and double-billing during the cutover window |
Messaging / ISO 20022 migration | Payment message formats and structured data fields (e.g., MT940 to Camt.053) | Structured data completeness: most legacy systems don’t capture the fields the new format requires, and the missing fields only surface on rejected messages |
Migration Type
PSP / gateway switch
Issuer-processor / card portfolio migration
Billing / subscription platform migration
Messaging / ISO 20022 migration
What Moves
Stored card tokens, checkout integration, webhook handling, and the reporting feeds reading off both
Cardholder profiles, PANs, ledger and interest configuration, scheme integrations
Subscription records, renewal cycles, dunning, and invoicing logic
Payment message formats and structured data fields (e.g., MT940 to Camt.053)
Primary Technical Risk
Token re-association and authorization-rate normalization with the new acquiring relationship
PAN transfer at scale under scheme-approved processes, plus ledger and product configuration parity
Renewal-cycle timing errors and double-billing during the cutover window
Structured data completeness: most legacy systems don’t capture the fields the new format requires, and the missing fields only surface on rejected messages
For messaging, there is a deadline that other rows don’t have, since SWIFT removes unstructured postal address information from payments after 14 November 2026, whereas in April, 61.2% of payment messages had unstructured debtor postal address information. Therefore, if the ISO 20022 migration only captures fields from legacy systems, it will not be complete.
NimbleCommerce, a Silicon Valley eCommerce company, needed a white-label platform capable of operating across national markets and supporting local payment methods. SPD Technology served as the sole technology vendor for the entire build, integrated 27 third-party payment systems, and took the platform live across the US, Canada, Mexico, Greece, the UK, and further European markets before the company was acquired. Each of those 27 behaved differently under load and error conditions, which is why migration effort scales with the number of distinct integration contracts in scope.
One program often spans two types at once — a billing system migration that also changes the acquirer, which inherits both risk profiles, and the single vs. multiple payment gateways question usually gets reopened in the same planning cycle.
Why Teams Bring SPD Technology Into a Payment Platform Migration
SPD Technology treats a migration as an engineering program — discovery and data mapping, dual-run architecture, token and data migration, hypercare through recovery — with one team owning architecture and execution and no hand-off in between. McKinsey’s 2025 Global Payments Report puts industry revenue at $2.5 trillion, drawn from $2.0 quadrillion in value flows across 3.6 trillion transactions, and every one of those flows sits on a platform someone will eventually move off.
Large-Scale Platform Consolidation
Eight acquired eCommerce platforms now run as a single consolidated system of 80+ services at Blackhawk Network, with a reporting layer processing 40M+ records per day across 100+ report types. Reaching that state required migrating data representing $30B in annual load value across eight incompatible data models, then proving the consolidated reporting output agreed with what each source platform had produced separately.
Parity work of that kind sets the schedule at this scale, further than the transfer itself does — which is exactly the shape of a card-portfolio migration, where the PAN file moves in days, and the ledger and interest configuration take months to reconcile.
Full-Cycle Payment Processing Build
The all-in-one omnicommerce system delivered for Poynt covered full-cycle payment processing, settlement, and third-party integration APIs, shipped within five months of a 5+ year partnership, and delivered PayFac-model transaction cost savings. A migration destination must support the entire end-to-end span, which is why questions about the scope of PayFac platform development belong in the destination assessment rather than in post-selection discovery. The client was later acquired, and SPD Technology was retained through the transition.
Phased Monolith Decomposition
Pulling the reseller portal out of the Poynt monolith took an eight-person team a full two years. That effort drove down platform support requirements while drastically reducing system interdependencies. Doing this kind of massive decomposition demands strict phased migration principles. You initially isolate a single bounded component. Testing that piece against your legacy path comes next, and only after passing do you move forward.
The engagement held one team across the full two years, owning both the architecture and the execution — which is what keeps a slice-by-slice program from stalling in the gaps between hand-offs, the point at which most phased migrations lose their schedule.
Your current architecture dictates the shape of an ideal engagement. Your specific exposure to stored credentials matters just as much. Some companies just need a single migration. Others benefit from building an orchestration layer so they can handle upcoming provider swaps purely through configuration tweaks. The fintech development outsourcing team here can evaluate your existing stack to map out whichever path fits best.
Key Takeaways
- Payment platform migration succeeds or fails on a small number of architecture decisions made before cutover — migration strategy, token/PAN transfer mechanism, dual-run duration, and rollback trigger.
- Dual-run is the default safe strategy for any business with recurring billing or stored payment credentials; big-bang cutover is defensible only for simple, low-volume, non-recurring setups.
- Token and PAN re-association errors are silent by default and surface weeks later, when a customer’s card is charged against the wrong record.
- Authorization rates predictably dip after cutover as issuers and networks re-learn the new merchant ID or BIN, which requires a budgeted normalization window.
- The rollback trigger must be a specific, measurable condition written into the go-live plan before cutover, because defining it during a live incident is too late.
- The old platform should stay live for a defined parallel-run window, typically 90–180 days, to serve as the fallback for late disputes, chargebacks, and audit questions.
In short: strategy, transfer mechanism, dual-run duration, and rollback trigger get settled weeks before the cutover date, and cutover only reveals which of the four was left too late.
FAQ
How long does a payment platform migration take?
Timelines range from under a week to more than a year, depending on the complexity tier. A virtual terminal setup with no stored credentials closes in days. A standard e-commerce payment processor migration with stored tokens and moderate volume takes 4–12 weeks. An issuer processor migration with PANs at scale runs 3–7 months, and a multi-market card program or treasury messaging migration with compliance dependencies runs 6–12 months or longer. Discovery is where schedules slip, since undocumented fee logic and renewal dependencies surface late.
How much does a payment platform migration cost?
Five categories drive the total: exit fees from the outgoing provider, setup and underwriting fees at the destination, engineering time for the dual-run build, operational overhead while two platforms run, and a rollback contingency. A standard PSP switch with stored tokens typically lands between $30,000 and $80,000, most of it engineering time across the 4–12 week build-and-test window. A complex issuer-processor or card-portfolio migration commonly runs from $150,000 into the high six figures, driven by ledger parity work and 90–180 days of parallel-run overhead. Provider exit and setup fees sit on top and vary by contract.
What is dual-run (parallel processing) in payment migration?
The dual run is a scenario in which both the outgoing and incoming platforms carry traffic for a set period. In a dual-run migration, you can direct some traffic to the new platform, validate its authorization behavior and reconciliation records against those from the old platform, and gradually increase the traffic ratio as the evidence accumulates. This is the most costly migration in terms of short-term operations, but this is the only migration with the proven fallback procedure: two platforms, two monitoring frameworks, two compliance surfaces.
Can you migrate card tokens without cardholders re-entering their card details?
Often, yes, via an approved processor-to-processor transfer, which involves transferring encrypted credential information from the outgoing provider directly to the incoming provider via a sanctioned procedure. Processor-to-processor transfer is conditional on both processors involved and on approval under your contract with the outgoing provider for export. In the case of an impossible route, the re-collection route would be used, which in turn results in customer churn for your subscription service. The transfer route should be established during the architecture stage, since the selected destination might not support it.
What causes authorization rates to drop after a payment migration?
Transactions are also considered based on the issuer/card network’s familiarity with the merchant’s identity. A new acquiring identity and descriptor would mean a fresh slate for risk scoring. Hence, early transaction volume is considered unfamiliar and rejected. Fraud scoring configuration never remains exactly alike, and retry logic could behave differently on the new platform.
Typically, the authorization rate stabilizes at its previous level after several weeks of increased volume, as the profile rebuilds. However, if a month later the rate is still below the baseline, there could be a configuration issue worth investigating.
Big-bang vs. phased migration: which is safer?
In most cases where the migration involves stored credentials or recurring charges, a phased migration is a much safer approach, as it keeps an active connection open until the migration proves itself under real traffic volume. The single advantage of the big-bang approach is that the cost of running the system in parallel would end immediately after the process is complete. The single disqualifying criterion of this approach is that any post-migration issues would become an immediate incident with no backup.
A payment gateway migration for a simple, low-volume, non-recurring merchant can reasonably be a big-bang approach. Anything holding stored credentials or active subscriptions should move in waves.
What should trigger a rollback during a payment migration?
A rollback trigger must be a specific, measurable condition agreed upon before cutover: an authorization rate below a stated percentage of the baseline for a stated period, settlement file failures exceeding a threshold, reconciliation breaks above an agreed count, or any confirmed token mismapping affecting live charges.
The authorization rate will normally recover within several weeks as volume reconstructs the profile. An authorization rate still below baseline after a month means a configuration issue that needs direct investigation.
What should trigger a rollback during a payment migration?
The rollback trigger has to be a measurable metric decided beforehand: the authorization rate is lower than the specified baseline, more settlement files fail than the specified number, more reconciliation errors than specified, or any token mismapping detected during testing.
Naming the metric, threshold, and time window is what will make your rollback possible. Trying to decide in the heat of battle is an argument, and the argument proceeds with customers being charged.
Do you need to keep the old payment platform after migration is complete?
Yes, keep it live for a defined period: 90 to 180 days is common among those with migration experience. Disputes, chargebacks, and refunds related to pre-migration activity often have to be resolved on the platform that captured them, and audits or other inquiries into historical activity proceed on their own timetable.
Retire it in stages: stop new traffic, close write access, export historical records into your own retention store, then terminate the contract.