Legacy Systems

For those unfamiliar, the phrase “rip-and-replace” in an IT context is the sort of project and related activities involving the total retirement of a legacy (old) system, and the institution of a new one.  Complicated legacy systems and aging enterprise apps eventually become inflexible and limiting; they fail to meet business requirements on an increasing basis, don’t serve staff, business partners, or constituents well, and stifle innovation and progress. 

Often, a rip of the old, and institution of the new, takes place – generally at extreme disruption to business, at great expense, and with much clean-up on the backside of the go-live.

The new system does everything the old one does, but much more in terms of user empowerment (new and more efficient methods of data entry, better reporting, better aesthetics, more intuitive paths of productivity, and so forth), it is better positioned for updates (more easily accomplished; affordable; less impacts), and also has modern constructs that positions it better for today’s expectation of “anytime/anywhere” access to process, data, and updates.

Modern IT business systems, and the associated “anytime/anywhere” requirement, means they must tether to mobile, laptops, tablets – shattering the “four walls” paradigm of the past.  Considerations of Cloud, business-to-business (B2B), and ready-adaptability means that legacy systems, creaky and anchored inside the four-walls paradigm, are often prime candidates for the rip-and-replace model:  Creation of an entirely new system, on a modern platform, to replace the old.

Along with rip-and-replace comes all the upheaval you would expect.  Tremendous effort to replicate process and services in the new system, while incorporating new.  Selection of a vendor, or spec’ing up of an existing one, for onboarding to the project.  Project definition and scope; creation; beta testing; monitoring and measure of milestones; user training – ultimately (usually) a Friday of last-day-of-use of the old system, and Monday’s “walk-in” for first-day-of-use of the new system.  Attendant is all of the anxiety and stress for IT, as well as Business, of whether the new system will perform up to expectations and requirements of real-world demands.  Minimally, you know the HelpDesk is going to be swamped with calls this day (and first week/s).

Too, there will be gaps and even breakages; it’s only a question of degree:  Reports that are not accurate, or comprehensive, or simply missing; business process that fails; data-entry that goes missing, or is hidden; data-sharing (to other systems or outside business allies/partnerships, etc.) that fails to occur; any number of things.  Clean up on the back side for various items is inevitable.

Is there an alternative to rip-and-replace?  Yes.

What if a legacy system could be treated as a service?  Today, it is possible to build applications that can incorporate the “service” of a legacy system, shattering its silo, and making its processes and data available to distributed applications, and serving the anytime/anywhere business expectation so critical for true fulfillment of today’s needs.

Thus, the legacy’s utility is now incorporated into modern methods for upgrade paths, user-facing screens, data-combining for comprehensive records/fields/reports.  On the backside, architectures and systems are made compatible with SOAP, iPaaS, SaaS, API standards, RAML, and others.

Easy connection between systems and what those offer is made via Connectors – available in libraries, and you can wield them through graphical drag-and-drop utilities in leveraging all manner of silo’d systems and data – crafting a comprehensive new one.  It really is extraordinary; no sophisticated developer training is necessary. 

Future integration needs are readily accommodated on a wholly new efficient and affordable basis.  Whether mainframe apps, custom-crafted in-house apps, or packaged apps, you can now create a combined whole to leverage data and process in a whole new way – quickly.

Compared to ongoing isolation, huge SOA projects, or rip-and-replace, orgs that adopt Legacy-as-a-Service (LaaS) will lower their risk and stress, achieve a faster ROI, and make better use of employees (both “front side of the screen” – users; and “back side of the screen” developers/planners). 

Now is the time to expose any legacy systems, and integrate them as services.  Establish an environment that positions you for API and SaaS initiatives.