anchor.diff:  
   A clean subscription migration implies that we stop the billing in the old system at the `currentBillingDate` (where `currentBillingDate` + 1 Period = `nextBillingDate`) and starts the billing in Kill Bill at the `nextBillingDate`. So how to achieve that result?
   
  -The first mandatory piece is to be able to extract those dates from the old billing system for each individual subscription attached to the account. In some billing systems, there is only some support to have a `billCycleDate` (`BCD`) at the account level (day of the month at which account is billed) and so that simplifies the problem. In some other cases different subscriptions can have their own individual schedules. Kill Bill supports all models through the use of billing alignments (and for reference, even a `SUBSCRIPTION_BUNDLE` alignment) defined in the catalog, so the starting point is to verify those alignments match the old system (this was part of the Pre-Requisites section).
  -
  -So from a billing point of view, we want to cancel the old subscription at `currentBillingDate` and start (the billing of) the subscription at `nextBillingDate`.
  +The first mandatory piece is to be able to extract those dates from the old billing system for each individual subscription attached to the account. In some billing systems, there is only some support to have a `billCycleDate` (`BCD`) at the account level (day of the month at which account is billed) and so that simplifies the problem. In some other cases different subscriptions can have their own individual schedules. Kill Bill supports all models through the use of billing alignments (and for reference, even a `SUBSCRIPTION_BUNDLE` alignment) defined in the catalog. So, the starting point is to verify those alignments match the old system (this was part of the Pre-Requisites section).
  +
  +From a billing point of view, we want to cancel the old subscription at `currentBillingDate` and start (the billing of) the subscription at `nextBillingDate`.
   
   ==== Entitlement Dates
   
  -A naive migration strategy would be to start the subscription in Kill Bill at `nextBillingDate`. While this works from a billing point of view, this causes some issues when the customer makes some changes (upgrade, downgrade, cancellation,...) during the interval of time such that `cutOverDate` <= t < `nextBillingDate`: In that interval of time, the subscription would have a future startDate (= `nextBillingDate`) so immediate changes could not be applied.
  -
  -So, we need to separate the date at which the subscription starts (`subscriptionStartDate`) and the date at which the invoicing starts: From an entitlement point of view, we could use the `cutOverDate` as the `subscriptionStartDate`, and this would work, but a better choice is to use the `originalSubscriptionStartDate` (date at which the subscription started in the old billing system). As far as entitlement goes, starting a subscription in the past is equivalent to starting it in the present, so using the Kill Bill `subscriptionStartDate` = `originalSubscriptionStartDate` solves the entitlement issue we mentionned above and preserve the `originalSubscriptionStartDate` of the subscription.
  +A naive migration strategy would be to start the subscription in Kill Bill at `nextBillingDate`. While this works from a billing point of view, this causes some issues when the customer makes some changes (upgrade, downgrade, cancellation,...) during the interval of time such that `cutOverDate` \<= t < `nextBillingDate`: In that interval of time, the subscription would have a future startDate (= `nextBillingDate`) so immediate changes could not be applied. Also, from an entitlement point of view, starting the subscription in the future means there is no service until we reach that date.
  +
  +So, we need to separate the date at which the subscription starts (`subscriptionStartDate`) and the date at which the invoicing starts: From an entitlement point of view, we could use the `cutOverDate` as the `subscriptionStartDate`, and this would work, but a better choice is to use the `originalSubscriptionStartDate` (date at which the subscription started in the old billing system). As far as entitlement goes, starting a subscription in the past is equivalent to starting it in the present, so using the Kill Bill `subscriptionStartDate` = `originalSubscriptionStartDate` solves the entitlement issue we mentionned above and it also preserves the `originalSubscriptionStartDate` of the subscription (which can be really useful for customer support when they interract with the customer).
   
   ==== Summary for Migration Dates
   
  
positive.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 otherwsie this is quite difficult to understand,
  * Treat each phase as a 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 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 the subscription with 2 phase `Plan` (`TRIAL`=15 days, followed by `EVERGREEN`):
  There are a few scenarios to consider:
  
  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 => TODO: Unsupported unless we violate the `originalSubscriptionStartDate` 
  
  ==== Pending Subscription Changes
  
  
negative.code: 
  At t = `cutOverDate`, the account is being migrated and for each existing active subscription in the old billing system, the following happens:
  
  1. We create a subscription with a starting date of `originalSubscriptionStartDate` (we will discuss the choice of the `Plan` in the next section)
  2. We stop the billing by inserting http://killbill.io/blog/blockingstate-abstractions[`BlockingState`] events (one event at t = `originalSubscriptionStartDate` with `isBlockBilling=true` and one event at t = `nextBillingDate` with `isBlockBilling=false`)
  
  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.
  