Technology changes fast and the lifetime of any computer system is getting shorter. The same applies to the world of CMS, where the current life expectancy of legacy systems is only around three years.
With an increasing number of available online content management systems, migration from one CMS to another is becoming more and more common. This can be a complex process that requires reengineering, a well-known concept in computer science. Here you will find a little bit of theory and a useful checklist to help you quickly assess uncertainty and risk in reengineering projects.
Technology changes fast and the lifetime of any computer system is getting shorter. The same applies to the world of CMS, where the current life expectancy of legacy systems is only around three years. Companies may wish to modernise their systems for many reasons, such as:
- To catch up on modern trends and technologies (who used responsive design five years ago?)
- To increase conversion rates
- Technical issues (performance, bugs)
- Lack of support from the system provider
- The growing number of mobile device users (today it is not unusual that traffic is evenly distributed between desktops, tablets and smartphones)
Regardless of the reason, the objective is no doubt to stay competitive in a rapidly changing market. This is the tricky part – how does a company make sure it stays on top of the game? How should it deal with the legacy system? Of course there is no simple answer, and the strategy will depend on the specific business case. Potential solutions to consider are:
Reverse engineering – the forgotten element
“Hey, it’s just a migration to a new platform! You know how the old system works. What could possibly go wrong?”
Believe it or not, this kind of statement is not unusual; the complexity of software modernisation is often severely underestimated. One element in particular is often forgotten: reverse engineering. Whether your project is about upgrading the system to a newer version or if it is a full reengineering, some sort of reverse engineering is necessary.
“Reverse engineering is the process of analyzing a subject system to identify the system’s components and their interrelationships and create representations of the system in another form or at a higher level of abstraction.”.
In my opinion, reengineering is the most difficult part of the modernisation process. Let’s have a look at the formal definition of reengineering:
“Re-engineering is the examination, analysis and alteration of an existing software system to reconstitute it in a new form, and the subsequent implementation of the new form ”.
The reengineering process assumes modification and evolution of existing software to meet given business requirements. It can be understood as an alteration of four general aspects:
- Conceptual (re-think)
- Requirements (re-specify)
- Design (re-design)
- Implementation (re-code)
More specifically, the modernisation process requires a great deal of technical and non-technical analysis.
Stakeholders. Everyone who has an interest (consciously or not) in the modernisation of the system. You need to understand their needs and interactions.
Requirements. You need to understand what was required from the old system and what is required from the new one.
Legacy system. Understanding the old system is a time-consuming but crucial process. The documentation is often missing, which means that the only way to understand the architecture and technical design is through source code analysis.
New system. Every CMS has a set of built-in features. It goes without saying that the new system has to improve both the users’ experience and the way editors work with the content. Therefore, it is crucial to analyse how the functionalities from the old system can be provided in the new system. It is highly beneficial to identify features that require extra development as these will be the most expensive.
Content analysis. CMS is all about the content. It is not enough to take technical considerations into account, it is also necessary to deal with the legacy content. Content analysis will help you to answer some significant questions: which parts of the content should be rewritten, which parts will stay in the new system, how will the different content types be mapped?
Data migration process. In a large enterprise scale system, the only option may be to automate the content migration. Automated content migration means that you can extract content from the old solution, map it onto the new one and place it in the new system. While many CMS platforms have a built-in export/import functionality, it is not always a straightforward process. Even though you might be able to export data from the old system into an XML file, for example, it may not be possible to import it into the new system. Make sure that the exported data is compatible with the new system.
The reengineering checklist
If you are a software architect, it is highly likely that you will be involved in a migration project sooner or later. Where would you start? I will help you a bit. Use the checklist below to evaluate uncertainty and identify potential risks. The more “no” answers you give, the higher the risk. Good luck!
- Do you know who the users are?
- Do you know how the users are grouped (etc. end-users, content editors, administrators).
- Do you know what the users expect from the system?
- Are you familiar with the issues they had with the old system?
- Do you know the functional requirements? Are they documented?
- Do you know how collect a backlog/WBS (if requirements are not documented)?
- Do you know the non-functional requirements (performance, security, usability)?
- Do you know how the content editors work with the old system?
- Do you know how the administrators work with the old system?
- Do you know what platform the old system uses (if any)?
- Do you know what the integration points with 3rd party systems are (if any)?
- Are you familiar with the technologies (platform, programming language) used in the old system (or do you have relevant competency in your team)?
- Do you have access to the source code of the old solution?
- Do you know which data model old system uses?
- Do you know which required functionalities are supported by the new platform “out-of-the-box”?
- Do you know what extra implementation will have to be done (what is not supported by the new platform)?
- Do you know if the editors/administrators know the new system (or if training is planned)?
- Do you know how the content is structured in the source system (information architecture)?
- Do you know if the content can be organised in the same way in the destination system?
- Do you know the content types?
- Do you know how much content is kept in the old system?
- Do you know how to map the content types from the old system into the new system?
- Do you know how the content will be moved into the new system (manually, automatically)?
- Do you know how to export content from the old system?
- Do you know how to import content into the new system?