anchor.diff:  == 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 highlight some specific areas of concern.
  -
  -The assumption is that there is already an internal or third party billing system in place:
  -
  -* It receives some live traffic, and migration should not cause any downtime
  -* It contains existing state (subscriptions, invoices, ...) that need to be migrated without impacting customers
  -* It provides a UI for customer service (CS) use to handle customer tickets
  -* It provides state/data that is used by accounting/financial departments
  -* One or several systems in the company are interracting with that billing system through API calls or by ETLing data
  +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 highlight 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 when 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 need 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) use to handle customer tickets and that functionality still need 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.
   
  
positive.code: 
  Note that subscription apis to create subscription don't allow to specify different dates for billing and entitlement, so additional apis calls to insert the `BlockingState` are required. While less practical, this is not really an issue because at that stage we have set `AUTO_INVOICING_OFF` at the account level so nothing will happen and atomicity is not required.
  
  ==== Multi-Phase Plans
  
  There is another concern we did not discuss yet when migrating subscriptions for multi-phase `Plans`. Kill Bill supports `Plans` with multiple `PlanPhases` (such as `TRIAL`, `DISCOUNT`, `EVERGREEN`). The old billing system may support that concept as well, or it could be that such concepts are implemented in an entirely different fashion:
  
  
negative.code: Some billing system will also allow to schedule future changes associated to a subscription (such as upgrading a subscription in the future or cancelling a subscription in the future,..). During migration it is important to keep track of those future changes. Fortunately this is fairly straight-forward using the Kill Bill apis to change Plan or cancel in the future,...
  
  
  == Conclusion
  
  
  
  
  