Information Technology Project Circle, Pune

DATA MIGRATION TO THE CDR ! TEM

TRATEG! ON "INANCIA# DATA

Date: 10 Nov 2009 Introduction: A standard approach to deal with migration of financial data from the existing SSA level systems to the CDR based billing and customer care system has been under discussion for sometime now. The initial idea was that in view of the fact that BS ! maintains accounts on a calendar month basis" the migration should be carried out ensuring that cut off for financial data would always happen on the last day of a calendar month. #ith over $%% units to be migrated" this was putting a serious restriction on the number of units that can go live through the CDR system in a month. So we have to adopt a strategy that will enable &any day' migration. This is what we have tried at Bhopal. Bhopal has gone live as on %( ov )%%* and the issues are yet to get revealed. Still" the fact remains that a migration strategy allowing &any day' migration alone would enable us implement the CDR +ro,ect without serious time overruns. This document attempts to capture the uniform strategy for &any day' migration recommended for adoption by all units irrespective of the SSA level systems operated. This strategy has evolved in the light of understanding and experience so far on the CDR based system and ta-es into account the views of teams involved from both BS ! and TCS. Definitions: .. Source System: The SSA level systems currently managing the operations and data that are being migrated to the CDR based customer care and billing system. ). Target System/ The CDR based Customer Care and Billing System 01peration Support System2Business Support System being implemented to replace the &Source Systems'. $. Data Cut/ The activity of extracting the data re3uired in the target system for enabling its operations" from the source system. 4. Cutover Date/ The date on which the &data cut' is ta-en for the last time from the source system for being loaded into the target system. 5. Cutover Data/ The data that is extracted from the source system on the cutover date and loaded into the target system.

6. Go Live Date/ The date on which CDR system is opened for operation either fully or partially to the SSA level users. 7t is expected that +ayment 8anagement System 0+8S9 will be the first module going live from the target system. :. Interim Period/ The period between the &cut over' date and the &go live' date. This is the period during which the data transformation and loading is ta-ing place in the target system. 7t is expected that only payment acceptance activity will be allowed during this period. Since the target system remains &closed' during the interim period" these payments are re3uired to be processed in the source system. 7f all payments related to the interim period is proposed to be re;entered through the +8S of the target system" &cutover date' and &go live' date will be the same. There will be no &interim period' in such a situation. (. Opening Balance Creation Date/ The date on which the target system is ready to compute the opening balances of financial data under the prescribed <! codes. This readiness is determined by a confirmation by the sta-e holders that all transactions having an impact on the financial data related to the period prior to &go live' date have been identified and incorporated in the source and target systems so that the closing balances for those <! codes will directly agree with opening balances generated in the target system. *. Delta Period/ The period between the &go live' date and the 1pening Balance creation date. 7t is expected that there will be a gap of around a fortnight between the &cut over' date and 1B creation date to ensure that all offline and online payments related to the period prior to the &go live' date are processed in the source system before &delta data' is extracted. .%. Delta Data/ The data related to modifications that the &cut over data' have undergone in the source system. The assumption is that such modification will impact only the balances outstanding on invoices forming part of the &cut over' data on account of online and offline payments related to the period up to the &go live' date but posted and processed in the source system after the &data cut' is ta-en. ... Opening Balance/ The balance aggregated under the designated <! codes representing the balances wor-ed out from the data from the source system and loaded into the target system and updated for delta data. This will not ta-e into account the impact of any transactions performed in the CDR system beyond the &go live' moment. The accounting module of the CDR system will commence operations with these opening balances. Migration Strategy: A. All bi;8onthly Customers" whose billing cycle ends on the last day of the &go live' month" will be issued a single month's Bill from the source system for the period up to the end of the month immediately preceding the &go live' month. Data Cut will be ta-en only after these bills are issued. =or instance" assuming that &go live' date is &any day' in customers whose bill cycle covers the period from %. 1ct )%%* to $% ovember )%%*" bi;monthly ov )%%*" will be issued a

bill for the period from %. 1ct )%%* to $. 1ct )%%*. These customers will be issued another

monthly bill for the month of

ov )%%* from the target system. Beyond this" the customer will

receive bi;monthly bills as usual from the target system. 7n order to avoid hardships to the customers on account of this change" the pay by date related to the monthly bills issued to bi; monthly customers may be suitably extended. #hen the second monthly bills are issued to the customers from the CDR system" following the &balance carry forward' approach" all previous outstanding will also get included in it. Any notice to be issued to the customer to communicate this interim change in billing schedule will be ta-en care of by the SSA concerned B. All transactions related to the period up to &go live' date will be dealt with through the source system. The impact on account of this on the &cut over data' will be incorporated before the opening balances are created in the target system. The &delta data' migration should ta-e care of this. C. o transactions other than payment acceptance on invoices issued from the source system will be permitted in the source system beyond the point of &data cut'. >owever sales transactions that have no impact on &cut over data' can continue. D. Demand ote +ayments are not expected in the source system beyond the &cutover date'.

>owever" any demand notes in the pipeline as at the point of &data cut' and coming into the source system after the &data cut' will need special handling during &delta data' migration. 1ne option is to have these demand notes re;issued from the target system. ?. Any excess2double payments arising out of offline payments noted in the source system after the data cut is ta-en will also need special handling during &delta' migration. =. +ayments" during the delta period" which involves the restoration of service under suspension for non;payment of dues" shall be managed by the source system. <. +rovisional reconciliation of financial data will be done for all the prescribed <! Codes related to financial data migration" with reference to &cut over data'. >. A final reconciliation report to signoff the 1pening Balances by TCS and BS ! 0SSA9 will be generated after the &delta migration'. This report will present the 1pening Balances under the designated <! codes as on the &go live' date. 7. The Sub !edger for the period up to the month preceding the &go live' month will be generated in the source system. This should be completed before the &delta migration' is done. @. The Sub !edger for the partial month from the .st of the &go live' month to the day preceding the &go live' date will be processed in the source system. 7t is preferable that this too be done before the delta migration to ensure that the closing balances in the source system does not undergo further changes after the creation of opening balances in the CDR system. A. The Sub !edger for the &go live' month for the period from the &go live' date to the end of the month will be processed in the CDR system.

!. The full Sub !edger for the &go live' month will be compiled by combining the reports mentioned at @ B A above. 8. 7n case of a schedule which overlaps the <o !ive date 0schedule has collection details for the period before <o !ive date and after <o !ive date9" SSA will bifurcate it into two different schedules" first having the pre go live collection details" which will be posted in the source system and second having the post go live collection details" which will be posted in the target system. . 1pening balances as on the go live date will only be -nown after the delta migration is completed in the target system. This delta data will ta-e into account the delayed payment posting in the source billing system either because of the late recognition of offline payments or late posting of the payments received. This must be closed within .%;.5 days after go live date. 1. Any feed to the Accounting 8odule of the CDR system will commence only after the reconciliation reports for the opening balances are created and signed off by the sta-e holders. +. The first &trial balance' from the target system accounting module will indicate the opening balance as on the &go live' date 0expected to have been reconciled with closing balances from the source system9 and the summary of transactions beyond the &go live' point and closing balances as at the close of the &go live' month. C. Beyond the &go live' month" all lin-ages with the source system will stand severed and the entire TR related operations will be performed only through the CDR system. ;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;;