Please note that this blog is archived and outdated. For the most current information click here!
Using the Firecracker Method for Legacy Migration
At the core of the IT industry today is digital transformation. The reason this transformation is necessary is due to the amount of legacy that IT teams are facing. Recognising this, WorkingMouse and Codebots documented multiple migration patterns for moving legacy applications to the cloud.
This article will step you through the more basic legacy migration pattern - the firecracker method.
When to use the firecracker method
This is generally used when the legacy application is small. For larger systems, the migration may be done over a large period of time and multiple small projects. Recently, we've seen businesses with critical processes built using Microsoft Access. Offline databases like Access and Excel are prime candidates to migrate into a modern web application using the firecracker method.
The process
The process is to gather knowledge about the legacy application and use that to build the new application. The diagram below shows a conceptual workflow for a firecracker migration.
The migration steps are as follows.
- Document the requirements of the old application to create a backlog for the new application.
- Remove old requirements that were not used or are no longer needed from the backlog.
- Reverse engineer the schema from the old database. If you are using Codebots, this step may be automated.
- Clean up the schema. This is a good opportunity to evaluate whether the schema contains any legacy.
- Design the UI. We would recommend consulting one of our user experience designers to evaluate the ease of the user journey.
- Develop and test the new application.
- Deploy and migrate the data. Because the new application is based on the schema of the existing application, provided no fundamental changes are made when cleaning up the schema, a data migration path is possible.
As mentioned earlier, this method works well for smaller applications where the number of dependent systems is minimal. When we start looking at larger systems the migration can't be done in one hit so we would recommend the divide and conquer pattern.
To be sure the new, digitally transformed applications of today don't become the legacy systems of tomorrow we recommend documentation. Only when an application is understood can it be modernised. This documentation process is an important part of the way we work and the technology we use. If you're looking to modernise your legacy software, get in contact to hear how we would approach the problem!
