B2B SaaS 구독 청구 플랫폼 이전 체크리스트 2026: 데이터·결제수단 마이그레이션
B2B SaaS 구독 청구 플랫폼 이전 체크리스트 2026: 데이터·결제수단 마이그레이션
B2B SaaS 구독 청구 플랫폼 이전은 customer CSV를 새 시스템에 올리는 작업이 아닙니다. 기존의 active, past_due, cancel_at_period_end가 새 플랫폼에서 같은 청구와 접근 권한을 만드는지, 사용량 집계와 미결제 invoice가 어디까지 이어지는지, 저장된 payment method를 옮길 수 있는지가 함께 맞아야 합니다.
가장 위험한 순간은 새 플랫폼을 켠 날보다 두 시스템이 서로 다른 금액을 맞다고 말하는 날입니다. 구독은 두 번 갱신되고, usage는 한쪽에만 들어가며, 환불한 invoice가 매출로 다시 잡히거나, 결제수단 이전이 끝나지 않은 고객에게 자동 청구를 시도할 수 있습니다.
이 글은 2026년 7월 15일 확인한 Stripe·Chargebee·Paddle·Recurly 공식 자료를 출발점으로 사용합니다. 플랫폼별 지원 범위, 절차, 계약과 담당팀 개입 여부는 계정·지역·processor·payment method에 따라 달라질 수 있습니다. 고정 가격을 제시하거나 세무·법률·회계·매출 인식 판단을 대신하지 않습니다.
플랫폼 선택부터 다시 확인해야 한다면 B2B SaaS 구독 관리 플랫폼 비교 2026에서 Stripe Billing·Chargebee·Paddle·Recurly의 판매자 구조, gateway, dunning, usage billing 경계를 먼저 비교할 수 있습니다. 이번 글은 제품 선택 이후 실제 이전을 통제하는 방법에 집중합니다.
먼저 결론: mapping → dry run → dual run → cutover 순서를 바꾸지 않습니다
구독 청구 이전의 안전한 기본 순서는 다음과 같습니다.
[범위·책임 확정]
↓
[ID·상태·금액 mapping]
↓
[반복 가능한 dry run]
↓
[dual run + reconciliation]
↓
[cutover + write freeze]
↓
[rollback 판단]
↓
[post-cutover audit]
핵심은 데이터를 많이 옮기는 것이 아니라 어느 단계에서도 원본과 결과를 비교할 수 있게 만드는 것입니다. 각 import row에는 원본 ID, 새 ID, migration batch ID, 변환 규칙 버전, 실행 시각과 결과를 남깁니다. 수량만 맞추지 말고 금액·상태·다음 청구 시점까지 맞춰야 합니다.
프로젝트 시작 전에 다음 다섯 문장을 한 페이지에 확정합니다.
- 기존 플랫폼에서 마지막으로 생성할 invoice의 경계는 언제인가.
- 새 플랫폼에서 처음 생성할 invoice의 경계는 언제인가.
- customer·subscription·payment method·usage·invoice의 기준 시스템은 단계별로 어디인가.
- cutover 중 허용하지 않을 쓰기 작업은 무엇인가.
- 어떤 오류와 고객 영향이 발생하면 rollback하는가.
이 문장에 owner와 timestamp가 없으면 cutover 당일 판단이 회의로 되돌아갑니다.
공식 문서는 가능 여부가 아니라 지원 경계를 확인하는 데 씁니다
Stripe 데이터 마이그레이션 개요는 결제 데이터 이전 절차를 확인하는 출발점이고, Stripe subscription import는 기존 구독을 Stripe Billing으로 가져오는 방법과 고려 사항을 다룹니다. payment method 이전은 일반 customer object import와 분리해 Stripe payment method imports에서 현재 절차와 지원 범위를 확인해야 합니다.
Chargebee의 구독 청구 마이그레이션 안내는 이전 프로젝트와 지원 절차를 검토하는 공식 출발점입니다. 다만 이 페이지는 개별 필드 변환이나 모든 processor 조합을 보장하는 API 명세가 아닙니다. 실제 범위는 구현 담당자와 source platform, gateway, payment method, history import 요구를 목록으로 맞춰 확인해야 합니다.
Paddle migration 문서는 migration 경로를 설명하고, data mapping과 workflow mapping은 객체와 운영 흐름을 비교하도록 안내합니다. 이 문서를 “모든 외부 provider의 토큰과 과거 거래를 self-service로 그대로 옮길 수 있다”는 뜻으로 읽어서는 안 됩니다. 특히 Paddle은 Merchant of Record 구조이므로 이전 전후 판매자, checkout, 고객 커뮤니케이션, 지급 경계를 별도로 확인합니다.
Recurly customer imports는 고객 import를, Recurly export overview와 data imports and exports는 export·import 범위를 확인하는 공식 자료입니다. export 파일이 있다는 사실과 해당 필드가 새 플랫폼에서 동일한 의미로 import된다는 사실은 다릅니다.
네 후보 모두에서 같은 질문을 서면으로 답받습니다.
| 확인 항목 | 질문 |
|---|---|
| 지원 방식 | self-service, API, CSV, vendor-assisted 중 무엇인가 |
| payment method | 어떤 processor·token type을 옮길 수 있고 재인증이 필요한가 |
| history | invoice·payment·refund·credit·usage history를 어디까지 가져오는가 |
| identifiers | 원본 ID를 custom field나 metadata로 보존할 수 있는가 |
| downtime | export, token transfer, import 사이 예상 제약은 무엇인가 |
| 실패 처리 | partial import, duplicate, retry, rollback은 어떻게 처리하는가 |
1단계: scope를 객체가 아니라 청구 경계로 자릅니다
“모든 데이터를 이전한다”는 scope는 검증할 수 없습니다. 데이터 객체를 세 가지 계층으로 나눕니다.
| 계층 | 예시 | 기본 처리 원칙 |
|---|---|---|
| 새 플랫폼에서 실행할 데이터 | customer, price, active subscription, payment method, current usage | import 후 실제 청구·갱신 동작 검증 |
| 조회와 대사에 필요한 history | invoice, payment, refund, credit note, failed attempt | import 또는 read-only archive 위치 명시 |
| 내부 시스템이 계속 소유할 데이터 | contract, entitlement, CRM renewal state, accounting reference | billing ID mapping만 연결 |
과거 invoice 전체를 새 플랫폼에 넣지 않더라도 고객 지원과 reconciliation에서 찾을 수 있어야 합니다. 반대로 history를 import했다고 해서 새 플랫폼에서 그 기록을 수정하거나 다시 청구할 수 있다고 가정하면 안 됩니다.
cohort도 함께 나눕니다.
- 월간·연간 자동 결제
- invoice/manual payment B2B 계약
- trial, paused, past due, cancel scheduled
- seat·add-on·tiered·usage-based plan
- multi-currency, coupon, credit balance 보유 고객
- refund·dispute·dunning 진행 중인 계정
- 향후 갱신일이 cutover window에 걸리는 계정
가장 단순한 정상 월간 카드 고객만 pilot에 넣으면 중요한 예외가 production에서 처음 나타납니다.
2단계: canonical ID와 상태 mapping을 먼저 고정합니다
mapping table은 이름이 같은 필드를 연결하는 표가 아니라 행동이 같은지 증명하는 표입니다.
| 원본 | 새 플랫폼 | 변환 규칙 | 검증 |
|---|---|---|---|
| customer/account | customer | 법인, workspace, billing account 중 기준 단위 선택 | 중복·병합·billing contact 확인 |
| product/plan/price | product/price | 통화, interval, tier, version을 immutable key로 분리 | sample invoice 금액 비교 |
| subscription/item | subscription/item | anchor, trial, proration, cancel, pause 상태 변환 | next invoice preview 비교 |
| payment method | token/payment method | processor 지원 절차와 동의·인증 요구 확인 | 실제 또는 허용된 test verification |
| usage | event/meter record | unit, timestamp, timezone, aggregation, idempotency 변환 | 기간별 unit·amount 합계 비교 |
| invoice/payment | invoice/transaction 또는 archive ref | open·paid·void·refunded 상태와 잔액 분리 | 건수보다 상태별 amount 대사 |
| credit/refund | credit note/refund 또는 reference | 사용 가능 잔액과 완료된 환급을 구분 | 고객 잔액·원거래 연결 확인 |
원본과 새 ID를 잇는 migration_ledger를 별도로 둡니다.
source_system
source_object_type
source_object_id
target_object_type
target_object_id
migration_batch_id
mapping_version
import_status
error_code
verified_at
이 ledger가 있어야 webhook, support ticket, refund 요청에서 이전 전 ID를 새 ID로 찾을 수 있습니다. 관리자 수동 수정과 migration 작업을 구분하려면 B2B SaaS 감사 로그·관리자 변경 추적 체크리스트의 actor, before/after, reason 필드를 함께 적용합니다.
3단계: payment method를 별도 workstream으로 분리합니다
payment method는 일반 CSV처럼 취급하지 않습니다. 저장된 결제수단의 이동 가능성은 source processor, destination processor, token type, 지역, 인증 상태, 각 사업자의 절차에 따라 달라질 수 있습니다.
다음 순서로 확인합니다.
- source platform과 실제 payment processor를 분리해 목록화합니다.
- card, bank debit, wallet 등 payment method type별 수량을 집계합니다.
- source export와 destination import가 모두 지원하는 조합을 확인합니다.
- token transfer 과정의 owner, 예상 일정, 식별자 mapping 방식을 서면으로 받습니다.
- 옮길 수 없는 결제수단과 재인증·재등록이 필요한 고객 cohort를 분리합니다.
- 고객 안내, secure update page, support escalation과 dunning 억제 기간을 준비합니다.
- 이전 후 default payment method와 다음 invoice의 실제 참조가 맞는지 검증합니다.
“payment method 10,000개 import 완료”만으로 성공 처리하지 않습니다. subscription이 새 payment method를 default로 참조하는지, 만료·실패 상태가 보존되는지, 첫 결제에서 추가 인증이나 고객 action이 필요한지 확인합니다.
결제 실패를 곧바로 churn으로 바꾸지 않는 상태 전이는 B2B SaaS 결제 실패·dunning 자동화 체크리스트와 연결합니다. migration cohort에는 잘못된 자동 retry나 취소가 실행되지 않도록 별도 campaign 또는 suppression 조건이 필요할 수 있습니다.
4단계: dry run은 같은 입력으로 반복 가능해야 합니다
dry run은 sandbox에 한 번 import해 보는 데서 끝나지 않습니다. production snapshot에서 민감 데이터를 안전하게 처리한 대표 cohort를 만들고, 같은 batch를 지운 뒤 다시 실행하거나 idempotent하게 재실행할 수 있어야 합니다.
dry run마다 다음 결과를 저장합니다.
| 결과 | 최소 검증 |
|---|---|
| row count | source eligible, attempted, created, skipped, failed 수량 |
| amount | currency별 open balance, credit balance, next invoice amount |
| date | period start/end, billing anchor, trial end, cancel date |
| status | active, paused, past due, cancel scheduled 등 cohort별 분포 |
| relationship | customer-subscription-price-payment method 연결 |
| behavior | renewal, upgrade, downgrade, refund, cancel, retry 실행 결과 |
| events | webhook 중복·순서 역전·재전송 시 내부 시스템 일치 |
오류 파일은 사람에게 읽히는 메시지만 남기지 말고 source_id, field, error_code, retryable, owner, resolution을 포함합니다. 수정된 mapping에는 버전을 올리고 이전 batch와 결과를 비교합니다.
usage 기반 계정은 중복 event, 늦게 도착한 event, 잘못된 단위와 invoice finalization 뒤 정정을 반드시 시험합니다. 상세 기준은 B2B SaaS 사용량 초과·usage-based billing 추적 감사 체크리스트와 함께 적용할 수 있습니다.
5단계: dual run은 이중 청구가 아니라 이중 계산입니다
dual run 기간에는 두 플랫폼이 같은 입력으로 예상 금액을 계산하되, 고객에게 실제 청구를 실행하는 시스템은 하나만 둡니다. 두 시스템의 자동 collection이 동시에 켜지면 검증이 아니라 이중 청구 위험이 됩니다.
권장 구조는 다음과 같습니다.
[계약·seat·usage 입력]
├──> [기존 플랫폼: 실제 invoice/collection]
└──> [새 플랫폼: draft/preview 또는 비수금 계산]
↓
[reconciliation warehouse]
reconciliation은 count가 아니라 business key와 amount로 수행합니다.
| 대사 축 | 비교 값 |
|---|---|
| customer | source/target ID, currency, billing profile, payment-method readiness |
| subscription | status, item, quantity, period, anchor, cancel/pause flag |
| usage | event count, unique ID count, unit total, late/corrected total |
| invoice | subtotal, discount, credit, tax 표시값, total, due date, currency |
| payment | attempted, succeeded, failed, refunded amount와 원거래 연결 |
| entitlement | plan·seat·add-on별 제품 접근 결과 |
금액 차이는 tolerance 하나로 덮지 않습니다. rounding, timezone, proration, discount allocation, usage cutoff, currency precision처럼 원인 코드로 분류합니다. 원인 없는 차이가 남아 있으면 cutover 승인을 미룹니다.
invoice·refund·credit가 서로 다른 사건으로 남는지 확인하려면 B2B SaaS 환불·크레딧 노트 추적 감사 체크리스트를 적용합니다.
6단계: cutover runbook에 write freeze와 책임자를 넣습니다
cutover는 “새 시스템 ON” 버튼이 아니라 순서가 있는 runbook입니다.
- 변경 승인과 go/no-go 시간을 기록합니다.
- product·price·coupon·subscription 수정과 수동 invoice 발행의 write freeze를 시작합니다.
- source의 마지막 delta export와 checksum을 저장합니다.
- pending usage, open invoice, dunning, refund, cancel 예약 목록을 별도 snapshot으로 남깁니다.
- payment method 이전 상태와 미지원 cohort를 다시 확인합니다.
- 최종 delta import를 실행하고 migration ledger를 갱신합니다.
- webhook endpoint, API credential, idempotency key와 event routing을 전환합니다.
- 기존 플랫폼의 자동 invoice·collection과 retry를 정해진 경계에서 중지합니다.
- 새 플랫폼의 invoice·collection을 승인된 cohort부터 단계적으로 엽니다.
- smoke cohort의 invoice preview, payment, refund, cancel, entitlement를 확인합니다.
- reconciliation과 고객 영향 지표를 보고 go/no-go를 다시 결정합니다.
- write freeze 해제 시각과 허용 작업을 공지합니다.
cutover window에 갱신이 예정된 고액 B2B 계정, trial 종료, cancel 예약, 사용량 마감 계정은 별도 watchlist로 둡니다. subscription status만 보고 기능을 끄지 않도록 B2B SaaS entitlement·feature flag 변경 추적 감사 체크리스트의 billing state와 access state 분리를 적용합니다.
7단계: rollback은 백업이 아니라 실행 가능한 분기입니다
rollback 계획에는 “문제가 생기면 원복”보다 구체적인 결정 기준이 필요합니다.
| trigger 예시 | 판단 질문 | 대응 |
|---|---|---|
| 중복 invoice·payment 발생 | 실제 고객 청구가 실행됐는가 | collection 중지, 영향 계정 격리, 원거래 기준 복구 |
| invoice amount 불일치 | 특정 cohort인가 전체 mapping 문제인가 | cohort 중지 또는 전체 rollback |
| payment method 참조 실패 | 재시도 전에 안전하게 고칠 수 있는가 | retry 억제, source 유지 또는 고객 업데이트 경로 전환 |
| usage 누락·중복 | 원본 event ledger로 재생 가능한가 | invoice finalization 중지, event 재처리 |
| entitlement 대량 오류 | billing은 맞고 접근 동기화만 틀린가 | access sync rollback, billing collection 별도 판단 |
| webhook 손실·폭주 | queue와 replay가 통제되는가 | consumer 중지, checkpoint부터 재생 |
중요한 제약은 cutover 뒤 새 플랫폼에서 생성된 invoice·payment·refund를 단순히 지우고 source로 돌아갈 수 없을 수 있다는 점입니다. rollback point를 다음처럼 구분합니다.
- pre-collection rollback: 새 플랫폼이 아직 실제 청구하지 않은 단계
- partial cohort rollback: 일부 cohort만 새 플랫폼에서 실행한 단계
- forward fix: 이미 외부 결제와 고객 문서가 생성돼 원복보다 정정이 안전한 단계
각 단계에 승인자, 중단 명령, credential·webhook 복구 순서, 고객 안내 owner를 붙입니다. rollback 테스트도 dry run에서 한 번 실행해야 합니다.
8단계: post-cutover audit는 첫 결제 성공 뒤에도 계속합니다
첫날 payment가 성공해도 이전이 끝난 것은 아닙니다. 최소 한 번의 월간 갱신 주기와 주요 연간 갱신 cohort를 관찰합니다.
24시간 점검
- duplicate customer·subscription·invoice가 없는가
- webhook error, retry queue, dead-letter가 증가하지 않는가
- invoice preview와 실제 invoice 금액이 승인된 범위 안에서 일치하는가
- payment method가 없는 active subscription이 생기지 않았는가
- entitlement 변경이 billing event와 추적 가능한가
7일 점검
- 결제 성공률·실패 분포가 migration 전 baseline과 비정상적으로 달라지지 않았는가
- dunning과 고객 알림이 중복 발송되지 않는가
- usage late arrival와 correction이 다음 invoice에 맞게 반영되는가
- refund·credit·cancel 요청을 support가 새 ID로 처리할 수 있는가
- finance·RevOps·CS가 같은 customer와 invoice를 찾을 수 있는가
첫 전체 billing cycle 점검
- cohort·currency·plan별 billed amount와 collected amount를 대사했는가
- proration, annual renewal, coupon, credit balance 예외를 검토했는가
- source platform에서 새로운 청구나 retry가 생성되지 않았는가
- archive와 migration ledger의 접근 권한·보존 owner를 확정했는가
- 임시 credential, elevated role, export file과 migration bucket을 정리했는가
취소 예약과 실제 서비스 종료를 혼동하지 않도록 B2B SaaS 구독 취소·churn reason 추적 감사 체크리스트의 cancel request, effective churn, migrated 상태를 분리합니다.
플랫폼별로 마지막에 다시 물어볼 질문
Stripe Billing
- subscription import 방식이 현재 데이터 모델과 API version에 맞는가.
- payment method import를 Stripe가 안내하는 migration 절차로 진행하는가.
- product·price·customer를 먼저 만들고 subscription을 연결하는 순서가 확정됐는가.
- imported subscription의 anchor, trial, cancel, invoice behavior를 sandbox에서 검증했는가.
Chargebee
- Chargebee migration 담당 범위와 우리 팀의 export·정제·검증 책임을 구분했는가.
- 기존 gateway와 새 gateway, token migration 조합을 서면 확인했는가.
- catalog, subscription, invoice history 중 실제 import 범위를 field 단위로 받았는가.
- marketing migration 안내를 기술적 보장으로 해석하지 않고 구현 계획을 별도 승인받았는가.
Paddle
- migration pathway, data mapping, workflow mapping 결과를 각각 문서화했는가.
- MoR 전환으로 checkout, 영수증, 환불, 분쟁, 고객 알림과 지급 흐름이 어떻게 바뀌는가.
- imported object와 transaction의 제한을 현재 문서·담당자에게 확인했는가.
- payment method가 없는 subscription과 고객 action이 필요한 cohort를 분리했는가.
Recurly
- customer import와 subscription·billing info·usage import를 같은 기능으로 가정하지 않았는가.
- export overview에서 필요한 dataset과 필드가 실제 제공되는지 확인했는가.
- customer import 결과를 subscription, invoice, payment method와 어떻게 연결할지 정했는가.
- source·target 양쪽 export로 cutover 후 대사를 재현할 수 있는가.
공개 전 최종 체크리스트
- source와 target에서 마지막·첫 invoice 경계를 확정했습니다.
- customer·subscription·payment method·usage·invoice별 기준 시스템을 정했습니다.
- source ID와 target ID를 migration ledger로 연결했습니다.
- 상태 이름이 아니라 상태의 행동을 mapping했습니다.
- payment method를 별도 workstream으로 분리하고 미지원 cohort를 찾았습니다.
- 대표 예외가 포함된 dry run을 반복 실행했습니다.
- dual run에서 실제 collection 시스템은 하나만 유지했습니다.
- count, amount, date, status, relationship을 모두 대사했습니다.
- write freeze와 마지막 delta export 순서를 runbook에 넣었습니다.
- rollback trigger, 승인자, 중단 명령과 forward-fix 경계를 정했습니다.
- dunning, refund, cancel, entitlement가 migration batch와 연결됩니다.
- 24시간, 7일, 첫 billing cycle 감사 owner와 대시보드를 준비했습니다.
- 세무·법률·회계·매출 인식 판단은 해당 전문가와 별도로 확인합니다.
마무리
구독 청구 플랫폼 이전의 품질은 import 성공률보다 다시 설명하고 재현할 수 있는가로 판단해야 합니다. customer와 subscription 수가 맞아도 다음 invoice 금액, payment method 참조, usage cutoff, refund 원거래와 entitlement가 맞지 않으면 이전은 끝난 것이 아닙니다.
mapping을 먼저 고정하고, 같은 dry run을 반복하며, dual run에서는 이중 청구 없이 이중 계산을 수행하십시오. cutover에는 write freeze와 마지막 delta를 넣고, rollback을 실제 분기로 연습한 뒤 첫 billing cycle까지 감사를 이어가야 합니다. 이 순서가 고객 영향과 운영자의 수동 복구 시간을 줄이는 가장 현실적인 기준입니다.
함께 보면 좋은 글
- B2B SaaS 구독 관리 플랫폼 비교 2026
- B2B SaaS 결제 실패·dunning 자동화 체크리스트
- B2B SaaS 사용량 초과·usage-based billing 추적 감사 체크리스트
- B2B SaaS entitlement·feature flag 변경 추적 감사 체크리스트
- B2B SaaS 환불·크레딧 노트 추적 감사 체크리스트
- B2B SaaS 구독 취소·churn reason 추적 감사 체크리스트
- B2B SaaS 감사 로그·관리자 변경 추적 체크리스트
공식 출처
- Stripe – Data migrations overview
- Stripe Billing – Import subscriptions
- Stripe – Payment method imports
- Stripe – Map payment data
- Chargebee – Subscription billing migration
- Chargebee – Implementation guide
- Paddle Developer – Migrate
- Paddle Developer – Plan data mapping
- Paddle Developer – Plan workflow mapping
- Paddle Developer – Migration pathways
- Recurly – Customer imports
- Recurly – Export overview
- Recurly – Data imports and exports
최종 확인일: 2026-07-15. import·export·payment method 이전 지원 범위와 절차는 변경될 수 있으므로 실제 이전 직전에 각 플랫폼 공식 문서와 담당자의 서면 범위를 다시 확인하세요.
About The Author
