anchor.diff:  
   ==== Pending Subscription Changes
   
  -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,...
  +Some billing systems 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 the 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
   
  -Migrations are always a difficult, lengthy process and risky endeavor. We have highlighed some of issues that need to be thought of and suggested a possible design (based on a set of simplification and work-arounds). Obviously each use case is different (migration happens from different systems with different characteristics, data set may be very different, and business requirements may also be different,...).
  +Migrations are always a difficult, lengthy process and risky endeavor. We have highlighed some of issues that need to be thought of and suggested a possible design (based on a set of simplification and work-arounds). Obviously each use case is different (migration happens from different systems with different characteristics, data set may be very different, and business requirements may also be different, ...).
   
   However, migrating to Kill Bill simplifies greatly the process for the following reasons:
   
  
positive.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 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.
  
negative.code: 
  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:
  
  * Use multiple subscriptions for each separate phase (hopefully those are linked by some mechanism otherwise this is quite difficult to understand)
  * Treat each phase as an upgrade/downgrade scenario (i.e move it to a different kind of plan)
  * ...
  
  There is obviously some amount of work to understand the old system's model, and how those will translate into the Kill Bill catalog (again part of the Pre-Requisites stage). So, assuming we are migrating a subscription into Kill Bill using a multi-phase `Plan`, we have to be cautious with the entitlement alignments and make sure we end up on the right phase.
  
  One strategy is to define more `Plans` in the Kill Bill catalog to include mono-phase versions of the multi-phase `Plans`. For example, assuming a subscription with a 2 phases `Plan` (`TRIAL`=15 days, followed by `EVERGREEN`), we could also create another `Plan` with only the last phase so as to migrate subscriptions that are already on the `EVERGREEN` phase. 
  
  