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: 
  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: However, keeping that data completely static is a challenge because customers may still require some invoice adjustements, payment refunds associated with this old data... So, a good strategy here is to keep the old billing system alive for a while after the migration has been completed and serve those invoices/payments from the old system, allowing customer service to still make the changes through the old system. After a while (maybe a few months) there will be very few such adjustments to make on those old invoices/payments and that data can be fetched and served from a static source. Isolated cases where customers still require some changes associated with these old invoices/payments cannot be made anymore but customer could still be satisfied by generating invoice or payment credit. At this point Accounting/Finance departments would be impacted minimally because the number of such requests becomes very few. So finally the old system can be fully unplugged.
  
  * **Finance/Acounting departement**: They will still require old invoice and payment data to run reports but it does not necessarily need to be part of Kill Bill. A good alternative is to provide some kind of a view that will merge both the old data (from old billing system) and the new data coming from Kill Bill. The old data could be ETLed from old billing system as long as it is alive and then data could be materialized after it has been extinct.
  
  ==== Clean Accounts
  
  A corollary of what we described earlier is that we should only migrate clean accounts, i.e accounts that have a $0 balance. Any other account would have unpaid invoices, and since we don't plan to migrate invoices, that balance is hard to carry over in a clean form.
  
  A good and easy strategy here is to do the migratiuon is several batches making sure we reach a point of convergence:
  
  1. A first migration batch with all clean accounts (hopefullly this accounts for the bulk of them)
  2. The current dunning strategy should be in place to first email customers, and moving through a gradual degrade of the service up to the point where subscriptions either become paid (and then account can be migrated) or subscriptions become cancelled (invoices are written off), and there is nothing to migrate for that account. This means unplugging the system will not happen overnight, this will be a gradual process (typicall most accounts are migrated within a week, and then syystem stays up for a few more months).
  3. The point of convergence is evenutally reached because:
    ** existing customers who have unpaid invoices either pay and get migrated or don't pay and 'die' in the old system
    ** new customers are already on the new system and so they will not impact the final date at which old system could be unplugged (more on that later)
  
  
  
  === How Does Migration Work?
  
  