approach is that each stage can be tested, further split for more control. This makes the transformation less risky, more manageable, and more cost effective. Stage Description Business Benefits Stage 1: Grouping of functionality Reduced effort and cost to This stage involves splitting the legacy testing NMS solution into framework and data plug-in. The data plug-in only handles data collection from the network element based on the specific protocol. Stage 2: Make interaction to framework Plug-in can be introduced from standardized the data collection layer and display layer Bring in full standardization for interaction based on SID and OSS/J to have minimal to nil dependency between framework and data collector. Now data collection and display systems provided by a different vendor or supplied by open source can be plugged in to the functional assembly. (Continued) Fundamentals of EMS, NMS and OSS/BSS (Continued) Stage Description Business Benefits Stage 3: Split framework components to Easier to fix bugs and easier to services maintain code The functionalities in the framework are More reuse and return over now highly coupled, hence introducing investment with a service new functionality or adding an open assembly source module is costly from integration perspective. We need to isolate functionality into services and make them loosely coupled. Stage 4: Standardize interaction Can introduce new services with between framework components minimal change in code The loosely coupled functionalities will Easily roll in and out of services need to interact based on standards. Framework can be used for multiple networks Enhancements A full-fledged NGNM address a This includes having a centralized multitude of issues in the registry, repository, and components telecom NMS domain. supporting publish-subscribe architecture. We can enhance it to have a MTOSI adapter. The staged migration can also be performed as a single stage activity where the single stage represents a product release that ensures that the legacy NMS pro