Migrating from Rational Rose RealTime (RoseRT) to DevOps Model RealTime is a significant project with challenges like compatibility, workflow adaptation, and team training. Due to its complexity, it requires a structured, phased approach for successful planning, testing, and adoption, which minimizes risks. This migration typically takes two to six months.
The following activities outline key steps for effective management:
Each one of these activities is described in the following sections.
To ensure a smooth and successful migration, the project must begin with a thorough planning and evaluation phase. This foundational step sets the stage for all subsequent activities.
The migration planning and evaluation phase focuses on two key objectives:
Evaluating the feasibility and complexity of the migration effort
Establishing a plan for the migration activities
Feasibility involves identifying the RoseRT features and workflows in use and comparing them with those supported by Model RealTime. It also includes assessing platform compatibility—such as host/target OS, build systems, and testing frameworks—to determine integration complexity.
Planning involves defining a preliminary timeline and identifying key personnel with expertise in RoseRT, Model RealTime, and the target application. It’s essential to allocate sufficient time for the test migration phase and coordinate with ongoing RoseRT development efforts.
Key roles include:
Test migration engineers
Training engineers
Additionally, the Model RealTime release schedule should be reviewed to select a stable target version. Coordination with the Model RealTime team is recommended to align with planned releases.
Note: If you encounter any issues during the planning or evaluation phase, please reach out to support, that is, hclswsupport@hcl-software.com via email for assistance.
With a clear plan in place and feasibility assessed, the next step is to put it into practice. The test migration phase does exactly that - it validates earlier assumptions and helps uncover real-world challenges before starting the full-scale migration.
The test migration phase is often the most resource-intensive part of the migration project. In this phase, a representative set of RoseRT models is imported into Model RealTime to generate code, build applications, and verify that functionality remains correct after migration. A successful outcome involves having all, or a significant portion, of the models migrated and validated within Model RealTime. As part of this process, it is important to document and, where possible, automate any required pre- or post-migration changes. Optimal import settings should also be captured to ensure consistency.
While the model import itself is usually straightforward, most of the complexity lies in adapting build and test environments to work with Model RealTime. Additional tools integrated with RoseRT may require reconfiguration to remain compatible. Past migration efforts indicate that unexpected issues often arise, some of which may require support from HCL or partner services. Since each project has unique aspects, migration planning must account for sufficient time and flexibility during the test migration phase.
The insights and experiences gained during test migration help shape the user training program, ensuring that engineers receive targeted instruction tailored to the real-world needs of the project.
The user training requirements depend on the general competence level of the development teams, but this must at least include sessions on how to use Model RealTime for engineers who know RoseRT, and sessions on the differences between the modeling languages used in RoseRT and Model RealTime. In many situations, it is also beneficial to include Eclipse-level training as part of the effort. One possible way of implementing the training is to base it on the "train the trainers" concept. This is based on identifying key engineers who will become the initial experts of Model RealTime, training these "power engineers" in the new tool, and then having them train the rest of the team.
Note: Model RealTime training courses are available in various formats, including onsite, remote, and self-paced options. Please reach out to the services team for details and scheduling assistance.
Once the team is trained and prepared, the project enters the migration week, a focused period where final model migration and handover to the full development team take place.
The "migration week" is the period that ends with the development team being up and running using Model RealTime in their daily work. The required time for this activity, of course, depends on the complexity of the models, and development environment, and the size of the design team. However, one week is a realistic estimate. During this period, the following should take place:
The final work is done in RoseRT, and a baseline is established
The models are migrated from RoseRT to Model RealTime
The complete development team gets access to Model RealTime, and training is performed
The establishment of a baseline in RoseRT should preferably also include running all regression test chains one last time and verifying that the models are correct in RoseRT before they are moved to Model RealTime. The model migration may start with some manual modifications of the RoseRT model if this has been deemed necessary during the test migration period. Then the models are imported into Model RealTime, and then potentially some manual post-processing is done on the imported models. Finally, application code is generated and built based on the imported models, and all regression test suites are executed to verify that the imported models are correct and that the application behavior is the same as before. The training of the development team does not have to take place during the migration week. However, from a timing point of view, it usually makes sense since the model migration in most cases is done by a subset of the engineers, so there are a number of days where the RoseRT models are frozen and the Model RealTime models are not yet available. It therefore makes sense to spend these days on user training. Experience has also shown that if users are trained too early, long before they actually will use Model RealTime frequently, then there usually will be a need for a refresh course once the migration is completed.
Following migration week, the team fully transitions to using Model RealTime. The post-migration phase supports this adoption with ongoing assistance and process improvements to maintain productivity.
When the team starts to use Model RealTime, experience has shown that the presence of engineers with Model RealTime knowledge facilitates the adoption of the product and reduces the initial problems for large teams to get up to speed using Model RealTime for development. If in-house expertise ("power users") exists, this may be enough, but if this is lacking, it is recommended to consider support from HCL services or from an HCL Partner. During the post-migration phase, it has been found very useful to develop a project-specific FAQ document as a means to quickly spread information to the team members. A scheme including daily meetings to discuss issues found when starting work with Model RealTime has also been used with good results. Based on the experiences of the team, it can also be a good idea to formalize practices by creating standardized preference settings or some small Eclipse plugins to streamline the workflow. However, usually such tasks are not urgent to be done right at the time of migration, even if they can be helpful.
Conclusion
Model RealTime is designed to support RoseRT users transitioning to a modern Eclipse-based environment. It preserves core modeling concepts and supports the same C++ runtime kernels, allowing most kernel adaptations to be reused with little or no modification.
However, upgrading and migrating development environments is inherently complex and requires careful project planning. For non-trivial projects or large teams, migration support from HCL or certified partners is strongly recommended.