anchor.diff:  
   So assuming we have N existing accounts to migrate, we end up one **newAccountCutOverDate** and N **cutOverDate**. We need to first move new accounts to Kill Bill before migrating any of the  existing accounts (i.e. `newAccountCutOverDate` < `cutOverDate{i, i E [1, N]}` because:
   
  -* Only when old billing system stops accepting new accounts, can we evaluate how many existing accounts there are (N becomes fixed at this point),
  -* This allows to verify that Kill Bill works as expected before we start migrating data.
  +* Only when old billing system stops accepting new accounts, can we compute how many existing accounts there are (N becomes fixed at this point),
  +* This also allows to verify that Kill Bill works as expected before we start migrating data.
   
   ==== Migration Framework
   
  
positive.code: ** Ability to migrate specific accounts (would set things like **cutOverDate** for that account)
  
  
  The choice of where those pieces are implemented really depends on the current architecture of the system. For instance if the code interracting with the existing billing system is well isolated, those new functions could take place at this level (client side). Conversely, if there are many components already interracting with the existing billing system, it might make sense to provide a new proxy server that encapsulate all that logic and have thpse components go through that proxy (and from an implementation point of view that proxy server could live in the same webapp as Kill Bill and access some new tables in the same database). 
  
  The figure below shows that the migration logic owns its own migration state. It is also able to make api calls to both old billing system and Kill Bill and provide an interface to the existing Billing&Payment Components (systems that currently interact with the old billing system). From a logical point of view, the migration logic has been shown in a seprate box, but again this could be implemented in various ways:
  
  image:https://github.com/killbill/killbill-docs/raw/v3/userguide/assets/img/migration/migration_logic.png[align=center]
  
  ==== Migration State
  
  As discussed previously, each existing account would be migrated independently from the others providing a small granularity (and avoiding a risky success/fail migration). It is also important to allow for a process that provides claririty on what failed and what succeeded and ability to restart things from where they failed. In essence migrating an account should be an idempotent process, so it 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
  * `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.
  
negative.code: 
  == 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 alignements 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 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 exiting 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. 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
  