anchor.diff:  Some billing system will also allow to schedule future changes associated to a subscription (such as upgrading a subscription in the future or cancelling a subscription in the future,..). During migration it is important to keep track of those future changes. Fortunately this is fairly straight-forward using the Kill Bill apis to change Plan or cancel in the future,...
   
   
  -
  -
  -
  +== Conclusion
  +
  +
  +
  +
  
positive.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.
  
  === How Does Migration Work?
  
  
negative.code: 
  == Strategy
  
  Like most complicated projects, it make sense to cut the projects in separate stages and also look for any amount of simplifications. Also, it makes sense to first make a migration while preserving things the way they are so as to not mix the migration itself with enhancements. Those could come at a later phase when things are stable.
  
  === What (Really) 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).
  
  === Simplifications
  
  ==== Historical Data, Invoices and Payments
  
  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:
  
  