anchor.diff:  
   * **Templates and Translations**: Kill Bill allows to configure the system using templates (e.g. invoice html visible to customer) and for http://docs.killbill.io/latest/internationalization.html[internationalization] (e.g translating plan names in different languages).
   
  -* **Payment plugins**: Kill Bill typically interacts with a payment gateway or processor through a http://docs.killbill.io/latest/payment_plugin.html[playment plugin]. We already have quite a few tested integrations out there so the work is either to test one of our payment plugin or to write a new one to integrate with the desired gateway/processor.
  -
  -* **Overdue Configuration**: Often called dunning in billing systems, this http://docs.killbill.io/latest/overdue.html[feature] lets you control what is happening when customers don't pay. Note that there is no obligation to try reproducing existing logic from the old billing system if this one was not satisfactory as this will not directly impact migration. Instead it is advised to configure it to provide the desired results. This step could also be ommitted and postponed until the end of the migration.
  -
  -* **Analytics**: This is also a good time to think about how financial reports will be computed and what kind of reports will be available for the C-level team. At this stage, one can become familiar with the data model and investigate how existing reports will be generated. Kill Bill also has an https://github.com/killbill/killbill-analytics-plugin[analytics plugin], which provides the following benefits:
  +* **Payment plugins**: Kill Bill typically interacts with a payment gateway or processor through a http://docs.killbill.io/latest/payment_plugin.html[playment plugin]. We already have quite a few tested integrations out there so the work is either to test one of our payment plugins or to write a new one to integrate with the desired gateway/processor.
  +
  +* **Overdue Configuration**: Often called dunning in billing systems, this http://docs.killbill.io/latest/overdue.html[feature] lets you control what is happening when customers don't pay. Note that there is no obligation to try reproducing existing logic from the old billing system if this one was not satisfactory as this will not directly impact migration. Instead it is advised to configure it to provide the desired results. This step could also be omitted and postponed until the end of the migration.
  +
  +* **Analytics**: This is also a good time to think about how financial reports will be computed and what kind of reports will be available for the financial team. At this stage, one can become familiar with the data model and investigate how existing reports will be generated. Kill Bill also has an https://github.com/killbill/killbill-analytics-plugin[analytics plugin], which provides the following benefits:
   ** Denormalized tables (on which queries become easier to run)
   ** Ability to generate custom reports
  -** UI side for visulatization inside KAUI if needed
  +** UI side for visualization inside KAUI if needed
   
   After the system has been configured, it is imperative to try out creating subscriptions with all the plans defined in the catalog, moving through phases by moving the Kill Bill `Clock`, performing upgrades/downgradse and at each step verifying the behavior of the system (invoice generation, payments, ...).
   
  
positive.code: 
  This provides the following benefits:
  
  1. It creates production-like data (actually, data is exactly like production except for fields such as CC number, names, ... that should be obfuscated). It can be used to start computing reports and bringing confidence to the C-level team that the new system will provide similar type of data/results. We suggest to configure the system with a default payment plugin inside Kill Bill (to avoid any interaction with payment gateway). The reporting only happens on the subscriptions and invoices but this is enough to guarantee that the system behaves correctly.
  2. It paves the way for the first stage of the migration where new accounts are directed towards Kill Bill.
  
  Regarding implementation, the forking of the stream can happen in the migration logic proxy. A good way to achieve this result is to write a servlet filter that forwards existing requests to the old billing system but also calls the matching Kill Bill endpoints.
  
negative.code: 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 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`).
  
  
  
  