We look through source code
For architects and civil engineers, there is an obligation to thoroughly inspect existing objects before changes (especially to load-bearing structural elements) may be made.
In software creation, this principle becomes more and more blurred with the years and decades of use. Legacy systems are strongly characterized by this.
At the same time, Legacy systems in particular are often of a business-critical nature, i.e. indispensable for day-to-day business.
The system cartography of legacy systems is comparable to a topographic map. It shows the system parts, their measured complexities, inner and outer couplings and the interfaces to the surrounding systems.
Thus it answers among other things the questions
- What is the condition of the legacy system?
- Which refurbishment measures are necessary, which are appropriate?
- Are modernization measures still economically feasible? If so, which ones?
- How long can the Legacy system still be used in an economically and technically reasonable way?
- Which technologies (database, security, ...) make sense for modernization?
- Which parts can be reused / modernized?
Legacy system mapping is essential for a deep understanding of the legacy system and its interdependencies. Every planning, be it
- the planning of the replacement,
- the modernization of the whole system or parts of it
- the automated transformation into a modern code or
- refactoring of the Legacy system