Legacy Systems from Java 1.2 to Rails Edge
Beginning a legacy conversion can seem daunting at first. To help simplify this task we recommend that you break the start up phase into three simultaneous parts: builds, database baseline, and requirements gathering. Creating and maintaining a constantly passing build for both your legacy system and the new Rails system is essential to a successful legacy conversion project. As few legacy systems are written to be testable or easy to deploy, spending the up-front time to create a CI build/deploy for both systems will save time during a crunch. Others should work on porting the current legacy database schema into a single Rails migration “as is”. We fondly refer to this as the “Single Migration Strategy”. While there are several methods for creating this migration, all these methods have the same goal; get your Rails initial migration to look exactly like the current database. Whether the system is internal or for a client there will be parts which are unknown to the team. Now is the time to explore this system and ask basic questions of the customer. Begin to identify simple or common parts of the system which are going to be easy targets for conversion. Try new things like writing these features down as acceptance tests in either Selenium, Webrat, or Cucumber formats as these can be used on both legacy and rails systems with little to no changes.
There are many issues that arise from working with legacy databases. Legacy systems often play a gatekeeper role to the database housing some if not all of the data integrity logic. Rails also likes to play this gatekeeper role, but during a legacy conversion it may not yet contain enough logic to do so. The legacy database also likely has its own conventions for table names, column names and sequences that don’t conform to Rails conventions. Solving these conflicts requires being very careful how you go about refactoring the schema, being exacting in your column specifications and model validations, and taking time to tease out all integrity logic, hidden or otherwise. Coding towards multiple databases or converting database backends only compounds these issues.
There are many other techniques and tools that can help smooth the conversion process. Balancing a large conversion effort with the need for new functionality can be a difficult task. Many of seemingly mammoth tasks can be broken down by utilizing the principles of REST throughout the conversion process. Shared login can be a scary beast when two systems must act as one seamless site. Not to worry, our Shared Authentication Pattern allows one system to be the authority and makes changing that authority a breeze. Tools are an essential asset to a developer so we will cover those we have found the most indispensable.
We believe that this three year conversion project has left us with many valuable lessons to share with the Rails community and anyone who may be embarking on a legacy application conversion.