Migrate from Zuora to Kill Bill

How to migrate from Zuora to Kill Bill without losing billing history

If a renewal, a pricing change, a data residency requirement or lock-in is pushing you toward self-hosted billing, the migration means exporting accounts, subscriptions and invoices from Zuora, rebuilding the product catalog in Kill Bill, and reconnecting your payment gateways. The effort depends mostly on catalog complexity (plans, add-ons, price books, usage rules) and on the volume of historical invoices and payment records you need to carry across. Start by inventorying both before you commit to a timeline, because the catalog is usually the largest unknown.

Internal platform or finance engineering teams usually own this work, often with an implementation partner for the Java deployment, plugin work and data loading. Kill Bill is free under the Apache License 2.0, but it ships with no support or SLA by default, so you need to decide in advance who will fix a failed invoice run at 2 a.m. Confirm with your partner whether they will cover upgrades such as moving within the 0.24.x line, and plan for the database operations that Kill Bill's MySQL-based core team setup requires. Check the Kill Bill project on GitHub for the current release notes before you pin a version.

Keep Zuora running in read-only mode until you have reconciled at least one full invoice run in Kill Bill against the Zuora output for the same accounts. Compare invoice totals, tax lines, credits and proration results account by account, and keep the Zuora exports as your audit copy. Agree in writing with Zuora which data source exports you will download and within what window, since export access is time-limited. Ask your finance team to sign off on the reconciliation criteria before cutover, so that a difference is either explained or treated as a defect.

Which Zuora capabilities map cleanly to Kill Bill and which need rework

This table maps each main Zuora Billing capability to its Kill Bill counterpart and marks it as clean, needs rework or gap. Read the status as a planning signal, not a verdict: rework rows need design work before cutover, and gap rows need a decision on whether to build, buy or drop the feature. Confirm every row against the plugins and your own requirements before you commit.

Zuora capability	Kill Bill equivalent	Status
Accounts and customer hierarchy	Accounts with multi-tenant isolation per tenant; parent-child hierarchy depends on how your team models it	Needs rework
Subscriptions, upgrades and downgrades	Recurring subscriptions with plan changes, supported natively	Clean
Product catalog	Catalog is defined in Kill Bill's own format, so Zuora product and rate plan structures must be translated and tested	Needs rework
Usage rating and recurring usage billing	Usage-based subscriptions are supported; rating rules for your specific pricing must be rebuilt and validated against Zuora output	Needs rework
Invoicing and invoice runs	Invoices and invoice generation are supported; invoice templates and numbering must be matched to your existing formats	Needs rework
Credits and adjustments	Invoices and credits are supported; confirm how your existing credit balances and refund flows map	Clean
Payment gateway integrations	Gateway connections run as plugins, such as Stripe, Braintree and PayPal; any gateway without a plugin needs custom development	Needs rework
Tax and fraud integrations	Tax and fraud providers connect through plugins; confirm the specific providers you use have a plugin or plan a custom one	Gap
Revenue recognition and financial reporting	Not established from the supplied facts; confirm against the Kill Bill plugin set and your finance team's reporting needs	Gap
Back-office UI	Kaui provides role-based access for support, product configuration, finance reporting and testing	Clean

What moves cleanly, what needs rework and what stays behind

Sort the Zuora estate into three groups before you plan any import. The first group is records that can be extracted and re-imported: accounts, subscriptions and invoice history held as data. Export these through Zuora's data source exports, then load them into Kill Bill through its REST APIs, starting with accounts, then subscriptions, then invoices and payments so that references resolve in order. Invoice history is best imported as historical record for audit and customer statements, not as a stream of new invoice runs. Confirm the export formats and object coverage in your own Zuora tenant, because the export window and file formats are set by Zuora and can change.

The second group is logic that must be re-expressed, and this is where most of the effort sits. Catalog rules, including plans, phases, price tiers and add-ons, have to be rebuilt in Kill Bill's catalog definition. Proration behavior, usage rating and dunning rules are not copied across as settings. Your finance and billing team should write down each rule with a worked example, then run the same sample subscriptions through both systems and compare the outputs line by line. Keep those comparisons as evidence for the reconciliation of the first invoice runs. Kill Bill's behavior for usage and dunning depends on your configuration and plugins, so verify each rule rather than assuming equivalence.

The third group does not transfer. Stored card tokens held inside Zuora's gateway integrations are the main case. Card credentials generally need a separate token migration, either with the payment processor or through a PCI-compliant vault that can export and receive them, and the processor must agree to accept the transfer. Ask your processor and Zuora, in writing, what the export includes and whether the receiving gateway will honor the tokens. Also treat Zuora-specific workflows, such as approval steps and custom notifications, as rebuild items, and do not expect historical legacy exports to be available once their download windows close. Plan a fallback that keeps customers on existing payment methods until the token path is proven.

Which data to extract from Zuora and which integrations to rebuild

Moving from Zuora to Kill Bill is mostly a question of which objects leave Zuora, in what state, and which connected systems must be rebuilt around the new billing core. Each card covers one object group or integration point, with the checks to run before the Zuora contract ends.

Accounts and contacts

Accounts hold the bill-to and sold-to records, payment method references, currency, time zone and tax settings that Kill Bill maps to its own account model. Confirm that every parent-child account relationship and each contact used for invoice delivery is exported, and that tax exemption and currency fields survive the mapping. Check for duplicate accounts created by past migrations, since these split invoice history across records. Export accounts first, because subscriptions and invoices reference them.

Subscriptions and amendments

Active subscriptions carry term dates, billing periods, renewal settings and the amendment history that explains how a plan changed over time. Kill Bill needs the current state of each subscription with its effective dates, so the import should preserve the next billing date and any future-dated changes. Compare a sample of subscriptions with their Zuora invoices to confirm that proration and charge timing are carried over. Confirm with Zuora in writing how far back amendment history can be exported.

Catalog and pricing

Zuora product catalogs, rate plans, charges and price tiers must be translated into Kill Bill's catalog definition before any subscription is imported. Map each charge type, billing period, tier and usage unit explicitly, and list the Zuora features that have no direct equivalent so they are rebuilt or dropped on purpose. Treat the catalog as a versioned artifact that finance signs off, because a mismatched price changes every renewal invoice after cutover.

Invoices and payments

Historical invoices, credit memos, payments and refunds are the audit trail for revenue and dunning, so they should be exported in full with their line items and tax amounts. Kill Bill imports invoices through its APIs and records payments against them, so reconcile invoice totals and open balances per account against the Zuora export before any new run. Keep the original Zuora invoice numbers as external references where possible so finance can trace documents across both systems.

Usage records

Usage records behind usage-based charges determine the next invoice for metered customers, and they are often the hardest data to recover. Export unbilled usage separately from billed usage, and confirm the time window, unit of measure and rating status of each record. Decide whether pending usage is billed in Zuora before cutover or replayed into Kill Bill, and document that decision with the finance team. Confirm the export limits for usage data with Zuora in writing before the contract ends.

Downstream integrations

Zuora usually feeds the general ledger, the ERP, the CRM, the tax engine and the payment gateways through connectors or scheduled files. Inventory every connector and file feed, record its direction and frequency, and decide which ones Kill Bill replaces through plugins and which the ERP or tax provider must receive directly. Reconnect each payment gateway in a test environment and confirm tokens or payment method references move correctly. Retention terms for exported data should be confirmed with Zuora in writing before the contract ends.

The migration sequence from inventory to decommission

The five steps move a Zuora billing estate into Kill Bill in a controlled order, with a written output at each stage so finance, engineering and the payment team sign off before Zuora is switched off. Each step gates the next, which keeps the first live invoice run from being the first real test.

Inventory the Zuora estate
List every object that drives billing: the product catalog and charge models, active subscriptions and amendments, usage feeds, payment gateways and payment method references, tax and fraud integrations, downstream ledger and CRM syncs, and the reports finance relies on. Owners for each item are named, and the export route for each object is recorded. Done means a catalog mapping sheet exists, lists every active product and charge, and has an agreed owner for every integration. Confirm with your Zuora administrator which data source exports are available on your contract, since the export window and file formats affect how much time you have to pull data.
Pilot one product line in a Kill Bill tenant
Stand up a non-production Kill Bill instance with its own tenant, install the payment gateway plugin your team intends to use, and load one product line or a small subset of accounts. The catalog is translated from the mapping sheet and the subscriptions are imported through the Kill Bill REST APIs, then compared against Zuora for the same accounts. Done means the pilot produces invoices whose line items, taxes, credits and balances match Zuora for the chosen accounts, and any gaps in the catalog translation are logged and fixed in the mapping sheet.
Run both systems in parallel
For a defined billing cycle, Zuora keeps invoicing live customers while Kill Bill generates its own invoices for the same subscriptions in a separate environment. Finance and billing operations reconcile the two sets line by line, covering amounts, proration, usage aggregation, credits, currency rounding and payment outcomes. Done means a reconciliation report shows every difference explained or fixed, with a named owner signing off each category of variance. Usage is the most common source of drift, so confirm that event data reaches both systems in the same form before the cycle starts.
Cut over with a signed checklist
Freeze changes in Zuora, including catalog edits and new subscriptions, then take the final exports and import the delta into the production Kill Bill tenant. Gateway credentials are moved or re-issued, and the payment team confirms that tokens or payment method references are valid, since card data cannot be exported from Zuora to Kill Bill in the same way as account records. The first live invoice run is executed and checked against the reconciliation thresholds agreed earlier. Done means a signed cutover checklist records the freeze time, the final export identifiers, the import counts, the first invoice run results and the rollback decision owner.
Decommission and retain records
After the first live cycles are stable, archive all Zuora exports, reconciliation reports and invoice copies in storage your retention policy covers, confirm that the records you must keep for tax, audit and customer disputes are readable outside Zuora, and close or downgrade gateway connections that Zuora used. Revoke Zuora API credentials and remove scheduled integrations. Done means a decommission record lists what was archived, where it is stored, who can access it, and the date Zuora access ended. Ask your finance and legal teams which retention periods apply, because these depend on jurisdiction and are not set by this migration.

How to run Zuora and Kill Bill in parallel and cut over safely

The parallel run is the control that proves Kill Bill bills the same customers the same way Zuora does before any invoice leaves the new system. Run both platforms against the same set of subscriptions and compare, per account and per invoice, the line items, invoice totals, tax amounts, proration on mid-period changes, credit and credit note application, and the outcome of each payment attempt. Payment outcomes deserve separate treatment: a matching amount is not enough if the gateway reference, decline code or retry schedule differs. Agree the comparison tolerances in writing before the run starts, including whether rounding differences are acceptable and who signs off on them. The number of billing cycles to compare is a scope decision. Confirm it with your finance and audit stakeholders, and set it in the statement of work so that the cutover date follows from evidence rather than from the calendar. Log every discrepancy in a single register with the account, invoice, expected and actual values, the Kill Bill catalog or plugin configuration involved, an owner and a resolution. Classify each item as a catalog translation error, a data import error or a genuine behavior difference, because each class is fixed in a different place.

The cutover window should be short, announced to finance and customer operations, and preceded by a freeze on catalog and subscription changes in Zuora. Without the freeze, subscriptions changed after the final extract never reach Kill Bill and the parallel evidence no longer describes production. Plan the final delta extract, the import through Kill Bill's APIs, the reconciliation of open balances and the gateway reconnection as one ordered runbook with a named decision owner for each step. Keep the freeze in force until the first production invoice run in Kill Bill has been reconciled. Define rollback criteria before the window opens. Typical criteria include an unreconciled difference in invoice totals above the tolerance agreed in writing, a failed payment-gateway test transaction, missing or duplicated subscriptions after import, and a failure to produce the first invoice run on schedule. Confirm with your own change board which party can authorize a rollback and how long Zuora must stay available to support it, which depends on your Zuora contract terms and the data export window your agreement allows.

How the migration changes with catalog size and starting point

A small catalog with a few plans, a handful of add-ons and few or no usage types is the simplest case. The work is mostly a faithful translation of each product and price into Kill Bill's catalog definition, followed by a direct import of a limited number of accounts and subscriptions. Effort concentrates on confirming that every active subscription maps to a plan that exists in Kill Bill, and on proving the first invoice run matches what Zuora would have produced.

Catalog translation: Write the product, plan, phase and price definitions once, then review them against a Zuora export of the active rate plans.
Account and subscription import: Load a small, known set of records through the Kill Bill APIs and check counts against the Zuora exports.
Payment method handling: Confirm how card tokens or gateway references move, since this is often the step that takes the most coordination with the gateway, not the billing data.
Parallel invoice run: Run one cycle in a test tenant and compare invoice totals, tax and credits line by line.
Smaller test surface: Fewer rules mean the regression matrix is short, though it still needs to cover proration on mid-cycle changes.

Before committing to this path, check that the catalog really is small by counting active rate plans, charge models and usage types in the current Zuora tenant, not in the original design documents.

What drives the cost and duration of a Zuora to Kill Bill migration

This table lists the factors that most change the effort and cost of moving from Zuora to Kill Bill, with how each one matters and how to keep it under control. Use it to scope a fixed-price quote, because most of the variance comes from catalog complexity, history volume and integrations rather than from the software itself.

Driver	Why it changes cost or effort	How to keep it down
Catalog complexity	Every product, plan, price book, add-on and usage charge must be translated into Kill Bill catalog definitions and tested for invoice output.	Retire unused plans before extraction and agree a mapping sheet with finance before any code is written.
Active subscriptions and invoice history	Each account, subscription and open balance must be imported through APIs and reconciled, so volume drives import runtime and checking time.	Migrate only active subscriptions with an opening balance and keep closed history in an archive export.
Usage volume and rating rules	Usage records and rating logic in Zuora must be reproduced in Kill Bill usage handling, and cutover must avoid double or missed charges.	Cut over usage at a billing period boundary and document each rating rule with a worked example.
Payment gateways and tax or fraud plugins	Each gateway, tax or fraud provider needs a Kill Bill plugin, configuration and certification testing, and some may need custom development.	Confirm which gateway plugins exist for your processors before scoping, and limit the first wave to the gateways that carry most volume.
Integration count	ERP, general ledger, CRM, data warehouse and customer portal integrations each need rebuilding against Kill Bill REST APIs and events.	Inventory every consumer of Zuora data and retire reports that nobody uses.
Reporting and revenue requirements	Revenue schedules, deferred revenue and audit reports may need to be rebuilt outside Kill Bill, which adds design and testing work.	Agree in writing which reports must match Zuora output and which can be rebuilt from new data.
In-house Java and database skills	Kill Bill is a Java server run in Tomcat with MySQL, MariaDB or PostgreSQL, so the team must operate the stack or pay a partner to do it.	Assess skills early, train named engineers and confirm JDK 11 and database versions in the migration plan.
Parallel-run length	Running Zuora and Kill Bill side by side doubles reconciliation and keeps the Zuora contract active, so each extra cycle adds cost.	Define exit criteria for reconciliation and set a fixed number of compared invoice runs before cutover.
One-time costs	Data extraction, catalog mapping, plugin work, migration scripts, reconciliation and cutover testing are paid once, usually to an internal team or a partner.	Ask for each activity as a separate line item in the written scope.
Recurring costs	Hosting, database operations, Kill Bill and plugin upgrades, monitoring and any support contract continue after go-live, and Kill Bill itself carries no support or SLA.	Ask whether support is retained separately and who owns upgrades, backups and on-call duties after cutover.

What usually goes wrong when moving billing off Zuora

Billing migrations rarely fail in the core engine. They fail at the edges: the data that never left the old system, the prices that shifted during translation, and the card tokens that cannot be moved. Each card below names one risk and the check that prevents it.

Incomplete exports or missing objects

A Zuora extract can look complete while leaving out amendments, usage history, credit memos or invoice items that were never linked to a subscription. Kill Bill will only hold what you load, so every object type needed for an open balance or a renewal date must be listed before the contract ends. Build a row count and a total-amount reconciliation per object, per account, and sign off the list with finance. Check the download window for each export and keep a dated archive of the raw files.

Catalog translation changing prices

Zuora product catalogs, charge models and tiered or volume pricing do not map one to one onto Kill Bill's catalog definition. A small mismatch in a currency rounding rule, a tier boundary or a billing period can change what a customer pays on the first run. Translate the catalog into a written mapping table, then generate test invoices for a sample of accounts across every plan and compare each line against the Zuora invoice for the same period before any live run.

Proration and credit mismatches

Mid-cycle upgrades, downgrades, cancellations and existing credit balances are where two billing engines most often disagree. Kill Bill calculates these from its own subscription events, so a subscription imported with the wrong start date or an unrecorded credit will produce a different proration result. Replay a set of known mid-cycle changes from historical data in a staging tenant and confirm that each proration and credit balance matches the original Zuora figure to the cent.

Lost or unmigrated payment tokens

Card tokens are tied to the gateway or vault that issued them, so exporting Zuora's billing records does not move the stored payment methods. If tokens are not transferred or re-collected, recurring charges fail on the first cycle after cutover. Confirm with Zuora and your gateway whether tokens can be exported, which format they arrive in, and whether each receiving gateway accepts them. Plan a customer re-authorization path for any token that cannot move, and test one charge per gateway before cutover.

Gateway reconnection delays

Kill Bill reaches payment processors through plugins deployed alongside the server, and each gateway account must be configured, credentialed and tested in the target environment. Gateway onboarding, sandbox approvals and webhook endpoint changes can take longer than the internal cutover plan assumes. Start gateway configuration in parallel with data extraction, register the new webhook URLs with each processor early, and keep the Zuora integration live until the first successful payment and failure cycle has run through Kill Bill.

No vendor support or SLA on Kill Bill

Kill Bill is open-source software under the Apache License 2.0 and includes no support or SLA, so a production billing incident has no contractual response path unless you arrange one. Your team, or a support partner you contract, must own plugin updates, database operations and upgrades. Before cutover, agree the escalation path in writing, define who can read and change the billing configuration, and decide how a failed invoice run will be detected and resolved.

Questions buyers ask before migrating from Zuora to Kill Bill

What does a migration from Zuora to Kill Bill cost, and what drives it?

The cost depends mainly on catalog complexity, data volume, the number of payment and tax integrations to rebuild, and how much plugin work is needed. Kill Bill itself is open-source software under the Apache License 2.0, so the license line is zero, but the spend moves to people and infrastructure: engineering time for the catalog translation and importer, plugin development or configuration, a Java and database platform team, and the parallel run. Some of that work may be paid to an implementation partner under a fixed-scope written agreement. Ask any quote to split one-time costs (extraction, mapping, import, testing, cutover) from recurring costs (hosting, database operations, upgrades, support), and to show the assumptions behind each line.

How long does a Zuora to Kill Bill migration take?

Duration varies with the number of products, price books, active subscriptions, invoice history and payment gateways in scope, so no single timeline applies. The fastest path usually has a small, clean catalog and few integrations. Longer projects involve usage rating rules that must be reproduced, tax and fraud plugins, historical invoice reconciliation and multiple tenants or entities. Ask for a timeline in the written scope that lists each phase and the client decisions it depends on, and check whether it includes at least one full parallel invoice run before cutover.

What does the migration need from our team?

Expect to supply people who know the Zuora configuration, the finance rules behind invoicing and revenue, and the payment gateway accounts. Finance must sign off on how each rate plan, charge and credit maps to Kill Bill concepts. Engineering must own the target environment, identity and access, backups and monitoring. Someone also needs authority to approve cutover and rollback. Ask the provider which decisions and reviews the client must make, and how long each review is expected to take, before work starts.

Can our own team migrate from Zuora to Kill Bill without a partner?

Yes, if you have engineers comfortable with Java services in Tomcat, REST APIs, MySQL or PostgreSQL, and event-driven systems, plus finance staff who can validate invoices line by line. Kill Bill's documentation covers installation and the REST API, and the Docker images for Kill Bill, Kaui and MariaDB make a test environment quick to build. The hard parts are usually the catalog translation, historical data, and plugins for gateways and tax, which need testing against real data. Weigh your team's capacity against a parallel run, and consider a fixed-scope engagement for only the components you cannot staff.

How do stored card tokens move from Zuora to Kill Bill?

Card data cannot be moved simply by exporting Zuora records, because tokens belong to the payment gateway or vault that holds them. The usual path is to ask the gateway or the current vault provider whether it can transfer tokens to your new processor, and under what PCI DSS obligations and fees. Confirm this early, since it can set the cutover date. Kill Bill connects to gateways such as Stripe, Braintree and PayPal through plugins, so you will need to confirm each gateway supports the token transfer you need. Ask Zuora which token export options it provides for your account and how long they take.

Does Kill Bill come with vendor support?

Kill Bill is open-source software, and the project states that it includes no support or SLA. It is maintained by The Billing Project, LLC, which owns the codebase and trademarks, and the project has been in production since 2010. Support therefore comes from your own engineers, from a community you can use, or from a contracted provider. DeployOpen offers ongoing support and upgrades as retainers, and most engagements are fixed-scope with deliverables agreed in writing. Ask any provider which incidents are covered, how upgrades are tested, and who is on call.

How do we run a parallel run before cutting over from Zuora?

Run Kill Bill alongside Zuora against the same subscriptions for at least one full billing cycle, then compare generated invoices, line items, taxes, credits and payment attempts. Use a separate Kill Bill tenant or environment so test invoices do not reach customers or gateways in live mode. Keep both systems' exports, reconcile totals per account and per run, and record every difference with a cause and a fix. Cutover should wait until differences are explained and signed off by finance. Confirm the parallel run length and reconciliation method in the written scope.

What should we confirm with Zuora before the contract ends?

Confirm the exact data you need and when you can export it, since Zuora's data source exports have download windows and some legacy exports may no longer be available. Ask about the format and completeness of account, subscription, invoice, payment and usage history, and whether they include the catalog and rate plan definitions you need to translate. Ask about the terms for continued access during migration, how the contract ends, and what happens to stored payment methods. Get these answers in writing and build your extraction checklist around them.

How DeployOpen scopes and runs a Kill Bill migration

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Zuora to Kill Bill, that means agreeing the scope in writing, rebuilding the catalog and data import in your environment, and handing over a runbook your own team can operate.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts.
The written scope lists which Zuora data sources, product catalog objects and payment gateways are in the migration.
Scope also names the Kill Bill plugins, Kaui roles and reconciliation reports that must be delivered.

How we build

We deploy Kill Bill as a WAR in Tomcat on infrastructure you control, with a MySQL, MariaDB or PostgreSQL backend.
We translate the catalog into Kill Bill configuration and test subscriptions and invoice runs in a non-production tenant first.
Payment gateway and tax plugins are configured, tested against sandbox credentials and documented before any cutover.

How we hand over

Handover includes configuration records, import scripts, runbooks and a reconciliation report for the first invoice runs.
We document the Zuora-to-Kill Bill mapping so finance and engineering can trace each invoice back to its source.
Your team receives training on Kaui and the operational procedures agreed in the written scope.

How we support

Ongoing support, upgrades and continuous testing are available as retainers after the migration closes.
Retainers can cover Kill Bill version upgrades, plugin maintenance and periodic backup and restore tests.
Confirm with DeployOpen which support levels, response expectations and compliance evidence are included before signing.