anchor.diff:  
   * **Templates and Translations**: Kill Bill allows to configure the system using templates (e.g. invoice html visible to customer) and for http://docs.killbill.io/latest/internationalization.html[internationalization] (e.g translating plan names in different languages).
   
  -* **Payment plugins**: Kill Bill typically interacts with a payment gateway or processor through a http://docs.killbill.io/latest/payment_plugin.html[playment plugin]. We already have quite a few tested integrations out there so the work is either to test one of our payment plugin or to write a new one to integrate with the desired gateway/processor.
  -
  -* **Overdue Configuration**: Often called dunning in billing systems, this http://docs.killbill.io/latest/overdue.html[feature] lets you control what is happening when customers don't pay. Note that there is no obligation to try reproducing existing logic from the old billing system if this one was not satisfactory as this will not directly impact migration. Instead it is advised to configure it to provide the desired results. This step could also be ommitted and postponed until the end of the migration.
  -
  -* **Analytics**: This is also a good time to think about how financial reports will be computed and what kind of reports will be available for the C-level team. At this stage, one can become familiar with the data model and investigate how existing reports will be generated. Kill Bill also has an https://github.com/killbill/killbill-analytics-plugin[analytics plugin], which provides the following benefits:
  +* **Payment plugins**: Kill Bill typically interacts with a payment gateway or processor through a http://docs.killbill.io/latest/payment_plugin.html[playment plugin]. We already have quite a few tested integrations out there so the work is either to test one of our payment plugins or to write a new one to integrate with the desired gateway/processor.
  +
  +* **Overdue Configuration**: Often called dunning in billing systems, this http://docs.killbill.io/latest/overdue.html[feature] lets you control what is happening when customers don't pay. Note that there is no obligation to try reproducing existing logic from the old billing system if this one was not satisfactory as this will not directly impact migration. Instead it is advised to configure it to provide the desired results. This step could also be omitted and postponed until the end of the migration.
  +
  +* **Analytics**: This is also a good time to think about how financial reports will be computed and what kind of reports will be available for the financial team. At this stage, one can become familiar with the data model and investigate how existing reports will be generated. Kill Bill also has an https://github.com/killbill/killbill-analytics-plugin[analytics plugin], which provides the following benefits:
   ** Denormalized tables (on which queries become easier to run)
   ** Ability to generate custom reports
  -** UI side for visulatization inside KAUI if needed
  +** UI side for visualization inside KAUI if needed
   
   After the system has been configured, it is imperative to try out creating subscriptions with all the plans defined in the catalog, moving through phases by moving the Kill Bill `Clock`, performing upgrades/downgradse and at each step verifying the behavior of the system (invoice generation, payments, ...).
   
  
positive.code: 
  This provides the following benefits:
  
  1. It creates production-like data (actually, data is exactly like production except for fields such as CC number, names, ... that should be obfuscated). It can be used to start computing reports and bringing confidence to the C-level team that the new system will provide similar type of data/results. We suggest to configure the system with a default payment plugin inside Kill Bill (to avoid any interaction with payment gateway). The reporting only happens on the subscriptions and invoices but this is enough to guarantee that the system behaves correctly.
  2. It paves the way for the first stage of the migration where new accounts are directed towards Kill Bill.
  
  Regarding implementation, the forking of the stream can happen in the migration logic proxy. A good way to achieve this result is to write a servlet filter that forwards existing requests to the old billing system but also calls the matching Kill Bill endpoints.
  
negative.code: 
  ==== Historical Data, Invoices and Payments
  
  Other state such as non-active subscriptions, past invoices, and payments *don't need* to be migrated into Kill Bill to have the system function correctly, but **that data may still need to be available in some fashion**. By not migrating that data into Kill Bill, this simplifies the problem:
  
  * **Non active subscriptions**: Migrating those means migrating more data; also it is often the case that the older the data, the less 'clean' it is and the harder it is to migrate (associated `Plans` may not be active anymore, previous bugs from existing billing systems may create data that is difficult to migrate, ...). Also, while this is feasible, this does not add much value unless one wants to also migrate past invoices.
  * **Past Invoices**: Those are difficult to migrate as such, because they can't simply be replayed by Kill Bill (if we were to migrate all subscriptions with their historical state and let Kill Bill catch up with invoices, the result would be a set of invoices not exactly identical to the original system (pro-ration logic would be different, catalog may have been configured slightly differently in the old system and in Kill Bill, ...) and so those would not be useful as they could not provide a real replacement for past invoices. Another strategy would be to insert them manually in the Kill Bill invoice table to make sure they exactly match, but then invoices and subscriptions would not correspond exactly and the system would try to correct the state. Also, such a route would require inserting data directly or providing custom endpoints to touch these tables, both of which are risky and error prone initiatives.
  * **Past Payments**: The same set of issues described for invoices apply to payments. They need to match exactly past invoices and the same set of challenges exists here.
  
  We identified the minimal state that needs to be migrated and also explored why migrating more is a difficult endeavor. The next question is whether this is a realistic strategy. One way to answer is to look at the use cases for this data (that we don't plan to migrate directly into Kill Bill), and the way we can make that info available in some fashion:
  
  * **Customer Use Case**: Customers may still need to access their old invoices and payments. Assuming this data is static, one could keep those (past invoices and payments) outside of the pure Kill Bill tables (that could still be in the same database with additional tables, or using an entirely different database) and **provide new apis that would fetch existing invoices and payments by merging old data with the new one from Kill Bill**.
  However, keeping that data completely static is a challenge because customers may still require some invoice adjustments, payment refunds associated with this old data, etc.  A good strategy is to keep the old billing system alive for a while after the migration has been completed and serve those invoices/payments from the old system, allowing customer service to still make the changes through the old system. After a while (maybe a few months), there will be very few such adjustments to make on those old invoices/payments and that data can be fetched and served from a static source. Isolated cases where customers still require some changes associated with these old invoices/payments cannot be made anymore but customer could still be satisfied by generating invoice or payment credit. At this point Accounting/Finance departments would be impacted minimally because the number of such requests becomes very small. So finally the old system can be fully unplugged.
  
  * **Finance/Accounting department**: These teams will still require old invoice and payment data to run reports but it does not necessarily need to be part of Kill Bill. A good alternative is to provide some kind of view that will merge both the old data (from the old billing system) and the new data coming from Kill Bill. The old data could be ETL'ed from the old billing system as long as it is alive and then that data could be frozen after it has been turned off.
  
  ==== Clean Accounts
  
  A corollary of what we described earlier is that we should only migrate clean accounts, i.e accounts that have a $0 balance. Any other account would have unpaid invoices, and since we don't plan on migrating invoices, that balance is hard to carry over in a clean form.
  
  A good and easy strategy here is to do the migration in several batches, making sure we reach a point of convergence:
  
  1. A first migration batch with all clean accounts (preferably, the bulk of them)
  2. The current dunning strategy should be in place to first email customers, and moving through a gradual degrade of the service up to the point where subscriptions either become paid (and then accounts can be migrated) or subscriptions become cancelled (invoices are written off), and there is nothing to migrate for that account. This means unplugging the system will not happen overnight, this will be a gradual process (typically most accounts are migrated within a week, and then the system stays up for a few more months).
  3. The point of convergence is eventually reached because:
    ** existing customers who have unpaid invoices either pay and get migrated or don't pay and become inactive in the old system
    ** new customers are already on the new system and so they will not impact the final date at which the old system could be unplugged (more on that later)
  
  
  