anchor.diff:  
   There is obviously some amount of work to understand the old system's model, and how those will translate into Kill Bill 's 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.
   
  -Assuming a subscription with a 2 phases `Plan` (`TRIAL`=15 days, followed by `EVERGREEN`). There are a few scenarios to consider:
  +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. 
  +
  +Alternatively, we could decide to only use the original `Plan`, and play with subscription alignments in the following way:
  +
   
   1. At t=`cutOverDate`, the subscription is already in the `EVERGREEN` phase; in this case we need to make sure we start directly into that phase. Fortunately, this is possible because the Kill Bill api to create subscription allows to specify on which phase to start (skipping previous phases).
   2. At t=`cutOverDate`, the subscription is still in TRIAL, but by chosing the `originalSubscriptionStartDate` as the start date of that subscription in Kill Bill we should end up exactly with the correct state. Let's take an example to illustrate that point:
  
positive.code: 
  == Strategy
  
  Like most complicated projects, it make sense to cut the projects in separate stages and also look for any amount of simplifications. 
  
  === What Needs to be Migrated?
  
  One must first decide on the data that must be migrated, so let's start by the minimum amount of data that needs to be migrated:
  
  * **Account data**: All the customer info such as name, email, phone, address, ... pretty much everything that would fit on the Kill Bill `Account` table. If additional data needs to be kept one could use custom fields to add key-value parameters attached to the account data.
  * **Active Subscriptions**: In order for users to still be billed and receive service, those need to be migrated and in a way to allow to switch from one system to the next with no (minimum) impact/visibility. Also note that since we are looking at the minimal amount of data to migrate we can ignore the historical data associated to a given subscription (e.g we don't migrate downgrade or upgrade that happened in the past, only the current state).
  
  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:
  
  
negative.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.
  
  
  Finally, we should explore a bit more the choice of the per-account `cutOverDate`: Is that better to chose that date close to `currentBillingDate` or `nextBillingDate`? A choice of `cutOverDate` close to `currentBillingDate` (right after), means that customer just got invoiced and so the chances for adjustements right after are bigger than if we were to wait. Since we want to minimize actions on the old system after customer got migrated, it seems a better choice would be to pick `cutOverDate` right before `nextBillingDate`. Of course in situations where customers have multiple subscriptions on different schedule (`SUBSCRIPTION` billing alignment), there is a choice to be made (probably favor the annual versus monthly and subscriptions on higer `Plans`).
  
  
  
  
  ==== 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:
  
  