networks. This is mostly the case with network equipment manufacturers who work on only one or two NMS solutions and has added functions to the NMS solutions with years of Fundamentals of EMS, NMS and OSS/BSS development. Years of development have made it a highly specialized NMS, but each time a new network is to be managed or new application needs to be added, there is considerable work involved to make the legacy NMS usable for the new requirement. In this case there would be many code segments and functionalities in the leg- acy NMS that can be reused and writing an adapter would mean losing the oppor- tunity to reuse it effectively. A complete rewrite from legacy NMS to NGNM by porting of applications will result in a majority of applications not working properly or ending up with major hard coding and tight coupling in the new framework that still may not be scalable. This makes the staged approach a good solution to migrate to NGNM from legacy NMS in a cost-effective manner. The staged migration has four main stages: Stage 1: Grouping of Functionality This stage involves splitting the legacy NMS solution into functional framework and data collector (see Figure 34.6). The data collector section only handles data collection from the network element based on the specific protocol and all func- tional framework is made independent of data and uses xml or predefined format files to manipulate data. The platform, GUI, and northbound interface compo- nents are scalable and does not usually have dependencies. Minor dependencies if any can be easily eliminated. This stage will mainly involve splitting some pro- cesses into multiple processes and removing hard coding specific to a particular format of data. Stage 2: Make Interactions to Framework Standardized and Data Collection Generic In this stage standardization is achieved for any interaction with the functional framework. The information/data model (SID) and interface model (OSS/J and MTOSI) is implemented at this stage. Now data collection and display systems