Achieving Zero Downtime Data Migration
Other migration challenges can be addressed through the following processes:
Inventory grouping
In practice, migrations are more complex than the scenarios described above. Often, several source data bases will need to be migrated, which means data from the different sources must be merged into one system. Even if there is only one migration source, additional data will need to be reconciled from NMS/EMS in the future. The incorporation of this data must be considered.
Besides delta reports, the migration framework should have the ability to match data from different sources via identifiers or rules based on matches between different attributes such as
locations, slots or port numbers.
Logging and reporting
Logging and reporting enable data statistics to be created and the progress of the migration project to be tracked. This includes not only the number of migrated objects, but also the classification of errors and statistics about open migration bugs. Project leaders and migration architects can then identify problem areas and fix migration rules and data quality issues faster, which in turn streamlines the entire data migration process and ensures the required migration quality is achieved.
Reconciling data from NMS/EMS
If the reconciliation of interfaces already exists in the legacy system, either a migration of these interfaces to the new system is required, or the operator must add additional reconciliation interfaces to other NMS and EMS. Reconciliation is an important function for keeping the data in the inventory system, which is the digital twin of the network infrastructure, up to date. Reconciling as much data as possible from the network is a major goal of any inventory solution.
Because a zero-downtime migration approach is similarly implemented as a daily reconciliation interface from NMS/EMS systems, the same framework is used to support migration of data from a legacy system as well as reconciliation of data from NMS/EMS or any other management systems. The functions previously explained are applicable for both.Migrating interfaces to new OSS/BSS
Like NMS/EMS, some operational or business support systems may have interfaces with the legacy inventory system. These interfaces must be migrated as well. There should be multiple options for OSS/BSS northbound integration as use cases can be very different. A broad interface with access to all data is crucial, one that self-extends in case of model changes in the database and delivers event-driven updates of the northbound systems.
A standard REST interface should provide query, create, update, and delete functionalities for all of the different objects in the database. The interface should also be self-extending, so if the administrator adds new entities or attributes to the database, the REST interface will be automatically extended and provide query, create, update, delete functionalities for the new entity and corresponding attributes without programming. An event API interface should be REST-based as well and should be able to send information to configurable REST endpoints. The interface logic should also be able to catch events generated by user activities.
Overall, data migration and data reconciliation can be challenging tasks. Having support from an experienced service provider and the right frameworks available significantly lower the risk of the project, allow for zero downtime, and enable an efficient go-live of the new system. This is essential to prevent operational damages and business impacts.
