anchor.diff:  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 `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.
  -
  -
  -Finally, we should explore a bit more the choice of the per-account `cutOverDate`: is that better to choose 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 the 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 schedules (`SUBSCRIPTION` billing alignment), there is a choice to be made (probably favor the annual versus monthly and subscriptions on higer `Plans`).
  +Note that subscription apis to create subscription don't allow you 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 it better to choose that date close to `currentBillingDate` or `nextBillingDate`? A choice of `cutOverDate` close to `currentBillingDate` (right after), means that the customer just got invoiced and so the chances for adjustments right after are bigger than if we were to wait. Since we want to minimize actions on the old system after the 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 schedules (`SUBSCRIPTION` billing alignment), there is a choice to be made (probably favor the annual versus monthly and subscriptions on higher `Plans`).
   
   
   
  
positive.code: 
  The main idea it to provide a migration endpoint, implemented in the migration logic proxy, that knows how to migrate each account individually. Each account migration is composed of several steps:
  
  1. **`migration_state` = `INIT`**: Create a an entry in the migration table.
  2. **`migration_state` = `ACCOUNT_MIGRATED`**: Migrate account data. This is relatively easy and low risk. The work consists in pulling account data from old billing system and mapping that to the Kill Bill data model. As mentioned before, additionnal info could be added as custom fields on the Kill Bill created `Account` (e.g ID of the account in the old system).
  3. **`migration_state` = `AUTO_INVOICING_OFF`**: Setup `AUTO_INVOICING_OFF` for the `Account` to prevent the system to trigger invoices when we start migrating the subscriptions.
  4. **`migration_state` = `SUBSCRIPTIONS_MIGRATED`**: Migrate active subscriptions. We will provide more detail in the next section on how that works, but the overall idea is to fetch all active subscriptions from the old billing system and recreate them in Kill Bill using the right date and using the right `Plan`. The goal is to get a clean cutover and avoid any misbilling (double billing, loss of revenue) or service disruption. Also note that in a system where there are dependencies among subscriptions (e.g. ADD_ON subscriptions), special care should be made to migrate them in the right order.
  5. **`migration_state` = `OLD_SUBSCRIPTIONS_CANCELLED`**: Cancel all subscriptions in the old billing system at the right time (more detail in the next section). This is a fairly risky step because this changes the state in the old billing system. This is *not* a point of 'no-return' but a point when rollback becomes difficult. Needless to say that cancellation code for the old billing system should have been tested carefully.
  6. **`migration_state` = `MIGRATED`**: Remove `AUTO_INVOICING_OFF` for the `Account`.
  
  
negative.code: 
  The first thing to discuss is the **cutOverDate**, that is the date at which Kill Bill starts handling requests. In fact, we made the assumption that the migration would happen on a live system (with no downtime), and that has two consequences:
  
  * The first consequence is that there needs to be a point in time where **new accounts** will be created in Kill Bill. While this is not a migration data issue (because those new accounts would never see the old system, so there is no data to migrate per say), we still need to define when is that **newAccountCutOverDate**
  * The second consequence is that because we will make that migration work with no downtime, it does not need to happen all at once. In fact, we propose to migrate the existing accounts on a per account basis. That way, each account is migrated independently (and occasional failures can be investigated and retried). So, we will have one **cutOverDate** per account.
  
  Assuming we have N existing accounts to migrate, we end up with one **newAccountCutOverDate** and N **cutOverDate**. We first need to 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 the 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 us to verify that Kill Bill works as expected before we start migrating existing data.
  