Last month, I discussed the real problem with legacy applications. It's not that these applications are old, nor is it that they are no longer in line with your organization's needs. Certainly, these are issues, but they wouldn't be critical issues if your legacy applications were easy to modify. Therefore, the real problem with legacy applications (and the reason they became "legacy" applications in the first place) is that these applications are difficult to change. Last month, I also discussed the general philosophy of how to optimally migrate legacy applications onto flexible, scalable environments so that the applications would be easy to grow and change as future needs dictated. The three main concepts I outlined were that all components of the target environment must be scalable, the migration must occur incrementally and the application itself should be partitioned into smaller functional units.

The first concept is easy. It just means you have to make sure you use scalable hardware and database software. You can satisfy that requirement by simply writing a check to the vendors of your choice. The other two requirements aren't as easy. They require design work and development time. They require that you use a technique that is tailored to achieving incremental migration. This month, I'll cover the basic steps of that technique.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access