anchor.diff:  ** One can run the migration many times on a test system (except for the cancellation of the active subscriptions on the old system, which can only happen once for obvious reasons)
   ** One can look closely at the data that was migrated and even run some tests by moving clock forward to ensure things will happen as expected in the future
   * **Altering System Behavior**:
  -** One can extend functionality through plugins (could intercept subscription calls, replace entirely catalog using catalog plugin api, modify invoice generation,...)
  +** One can extend functionality through plugins (could intercept subscription calls, replace entirely catalog using catalog plugin api, modify invoice generation, ...)
   ** One can maintain a fork of Kill Bill (just during the time of the migration) where migration logic could be inserted as needed
   * **Owning The Data**:
   ** Migrated data is easily available to run reports that will highlight potential issues
  
positive.code: 
  As discussed previously, each existing account would be migrated independently from the others providing a small granularity (and avoiding a risky 'success or fail all' type of migration). It is also important to allow for a process that provides clarity on what failed and what succeeded and the ability to restart things from where they failed. In essence, migrating an account should be an idempotent process, so if it fails part way through, things can be resumed. In order to achieve that result, the Migration Framework should own a `migration` table with the following fields (obviously one could add/remove fields as needed):
  
  * `account_key`: The unique identifier for the account to be migrated. Based on that key account data can be pulled from old billing system.
  * `migration_state`: We will see later that migrating an account is not an atomic operation so this will hold where we are in the migration process for that account
  * `last_error_msg`: Some indication of what fails to ease debugging and and resuming operation
  * `created_date`: Date when we first attempted to start the migration
  * `update_date`: Date when we last attempted to run the migration
  * `cut_over_date`: Date the migration completed (equals to `update_date` when migration has completed). Any subsequent requests after that date would be redirected to Kill Bill.
  
  
  == Pre-Requisites
  
  Before we can dig into more details on how the migration works, it is important to be ready to migrate these accounts. The readiness is something to be defined on a case by case, but there are a some things that are pretty much mandatory in all situations:
  
  === Setting up Kill Bill
  
  Migrating accounts to Kill Bill first implies that Kill Bill has been deployed and configured correctly. The point of that doc is not describe those steps (we have other http://docs.killbill.io/[docs] to explain that), but let's go through a few items that require special care:
  
  * **Catalog Creation**: The catalog should include all the `Plans` that were configured in the old billing system, so that subscription migration works. Special care should be made for billing alignments to ensure that customer ends up being billed at the same dates as they used to. Most probably the abstractions between the two worlds are slightly different (e.g in Kill Bill world we have the concept of a `PlanPhase` while in the old billing system each `PlanPhase` may correspond to a different `Plan` or event implemented differently).
  
  * **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/0.16/internationalization.html[internationalization] (e.g translating plan names in different languages).
  
  * **Payment plugins**: Kill Bill typically interracts with a payment gateway or processor through a http://docs.killbill.io/0.16/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 write a new one to integrate with the desired gateway/processor.
  
  * **Overdue Configuration**: Often called dunning in billing system, this http://docs.killbill.io/0.16/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 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 migration.
  
  * **Analytics**: This 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:
  ** Denormalized tables (on which queries become easier to run)
  ** Ability to generate custom reports
  ** UI side for visulatization 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 upgrade/downgrade and at each step verifying the behavior of the system (invoice generation, ...)
  
  === Behavioral Analysis
  
  
negative.code: == Overview
  
  This guide is intended to provide some guidelines for running migrations from an **existing billing system** to **Kill Bill**.
  It is by no mean an exact recipe book to follow, but it provides some recommendations on how to do things (based on previous experiences) and highlights some specific areas of concern. The assumption is that there is already an internal or third party billing system in place, and so the goal of the migration is to preserve the current state of the system and yet reach a point where this old system can be fully unplugged. The old billing system currently:
  
  * receives some live traffic, and migration should not cause any downtime
  * contains existing state (subscriptions, invoices, ...) that needs to be migrated without impacting customers
  * offers apis that are used by one or several systems within the company
  * provides a UI for customer service (CS) to handle customer tickets and that functionality still needs to exist in some form
  * provides state/data that is used by accounting/financial departments and this data will need to remain available for these departments
  
  The end goal of the migration is to make sure that we can **unplug completely the old billing system** and yet provide the same level of service (or better) for the customers and the various departments in the organization.
  