Page 2 of 3   « previous page   next page »

Phase by Phase Methodology Comparison
The following sections compare the Great Migrations Methodology to other approaches in the context of the standard software development lifecycle phases starting with setting scope and running through maintenance.

Setting Scope
Job one for your migration project will be to identify a set of one of more legacy systems that will be migrated. You will also have to scope the project in a way that meets the business case and minimizes disruption to other work.

Know What You Are Getting into and Why
New technology is usually hyped up as the magic solution to our business problems, and this can create excitement and momentum for a migration project. You should expect business and technical people in your organization as well as your technical service providers to try to use your project to cross sell technology, make application enhancements, address the maintenance backlog, and in general grow the migration into an ever-more-ambitious project. Some of this is taking advantage of economy of scale, but if it spirals out of control, the migration will end up trying to completely re-engineer the system and the processes that it serves. An out-of-control migration brings in technology for technology's sake, demands unnecessary technical risk, and promises to deliver an ever-expanding array of new business features.

Pace yourself: understand the technical features of the new platform - including updated in-house architecture and coding standards and SDLC changes. Research the most compelling features of the new platform, then decide if you will include them, defer them, or avoid them altogether. Remember also that new technology is like a puppy: it's cute and fun when you first bring it home, but it grows up to be a lot of ongoing responsibility. (Sidebar 3)

MANAGE DISRUPTION
Migrations can be disruptive if your development teams have to straddle the fence: supporting both the old and new world, but not firmly in either. This disruption means added complexity and operating costs, so a migration project should allow a quick transition if possible. If your legacy code base is too large to allow a quick transition and will be done over many release cycles, you'll have to make migration work part of your standard SDLC and portfolio management process. For very large migrations, the code base will be divided into migration sets that are converted with each release cycle.

One of the key benefits of a tool-assisted migration is speed of transition. The main effort is tuning the translator and this will be completed for each system before you decide to "cut over" to the new platform. Note also that legacy development streams can continue to evolve in parallel with translation tuning; there is no need for a code freeze until you are ready to translate the legacy code and begin maintaining it on the new platform.

Without adequate tool support, it will probably take you a very long time to migrate the code base, so you'll end up supporting both the legacy and new development streams, doing duplicate work, and merging changes. If you don't have resources to support parallel streams, you'll have to freeze or chill legacy development and shift those resources to the migration stream.

Key Point: The primary goal of a migration is to move an existing system efficiently to a new platform so the system team can resume work on meeting new business.

Summary
Remember that even a bare bones migration is complex and risky. It requires significant planning, preparation, and testing. Exploring all the possible technical and functional nice-to-haves demands more coordination and due diligence and the increased scope will increase cost and risk and ultimately reduce the ROI of the effort.

• Functional enhancements should be evaluated, scoped, scheduled, and delivered through your standard project methodology - not combined with migration work. The ideal functional scope of a migration project is functional equivalence; going beyond this may make sense, but it is beyond the scope of migration work.
• The ideal technical scope for a migration project is limited to the set of changes needed to provide functionally correct code that meets your architectural and coding standards for the new platform. Bear in mind that a high-yield translation tool is an enabler, not a constraint. It can help you improve existing source code by making API replacements and restructuring the code to meet new architectural standards. A translator can help you stretch your migration budget and allow for more, not less, technical improvements.

Functional Requirements
One of the first questions for any IT project is: What should the new system do? For a migration, the simplistic answer is: "the new system should do the same things as the legacy system." Now consider that most large-scale business systems are born through a big first release or launch and then they grow, and grow, and grow over a period of years: release after release, fix after fix, enhancement after enhancement. By the time a major business system is five years old, it can easily contain over 50 person-years of development effort. So the simplistic "do the same thing as the legacy system" leads to a huge question: how to figure out, in complete and accurate detail, everything the legacy system does. Answering this question is at the heart of the migration project.

Technical Requirements
Technical requirements include coding and architecture guidelines and library and component use standards that make the new code more maintainable, reusable, scalable, robust, etc. There may also be changes to configuration management policies, unit testing, and deployment and operating procedures. Scalability and robustness requirements in particular should also be formalized and new technologies should be stressed to ensure that their beauty is not just skin deep. Clearly the migration is more than just a language problem, and the migration team must carefully control both the total cost of conversion (TCC) as well as the long-term total cost of ownership (TCO). Careful selection of technical requirements is the key to controlling both of these costs.

Migration Requirements Gathering
Table 1 grades the effectiveness of various sources of requirements for a migration that aims to provide functional equivalence and also allows for architectural improvements that can lower maintenance costs.

Page 2 of 3   « previous page   next page »