Wouldn't it be nice if you could replace legacy applications without the pain of adapting to an off-the-shelf system or the high cost of rebuilding an existing system?
My observations and responses, although targeted at
SACWIS systems, can be applied to any enterprise legacy system upgrade.
3 Reasons to Replace Legacy Systems
At the conference, each session was focused on a different aspect of SACWIS systems. However, a common set of reasons to replace legacy systems started to surface. I heard multiple people say:
- Our hardware and operating system is out-dated causing maintenance contracts to be very costly
- The programming language used is out-dated making it expensive to accommodate modifications
- Reporting is inflexible or non-existent making outcomes and funding reporting tedious or impossible
Planning for SACWIS
I observed that every organization represented in my sessions had experienced the following when planning to replace their old legacy system:
- SACWIS systems take years of planning and documenting to prepare for development
- SACWIS systems are very expensive to create
- SACWIS systems are very expensive to maintain
- Running old and new systems in parallel is very expensive
In two different sessions, two very interesting and similar quotes were made, “People love systems that are about to be replaced” and “They loved the old system as soon as we told them it was going away”. It got me thinking about how the negative energy surrounding the rollout of new enterprise systems could be converted in to somehow making the project more successful.
I thought to myself after the conference that there has got to be a better way to replace legacy systems.
Then it dawned on me that end users and IT staff often create major assumptions that are incorrect. For instance, the following assumptions are used on most legacy replacement projects and they are not solid assumptions:
- AS400 systems are old technology and must be replaced
- Users won’t be able to learn a new system on their own and will need extensive training
- The new system and the legacy system need to be run in parallel for some period of time
- End user buy-in is tough to achieve
These assumptions, if truly incorrect... lead to poor planning that in turn lead to much higher costs.
A Better Rollout... ?
Here are the steps that I believe solve the majority of problems that occur during legacy replacement projects. By following these steps, project rollout will occur sooner, user buy-in will be higher, and cost will be substantially lower:
- Train programmers, users, managers on how databases work and about database best practices
- Rebuild existing system with modern tools
- Create exact look with NO NEW FEATURES
- Create exact business rules, which allows project team to learn existing business rules
- Make a skinnable system so it is able to be upgraded to newer styles in the future
- Migrate data to modern Database without modification to the structure
- Bad data is okay at this point because it was okay in the original system
- Rename the system and roll it out
- Improve reporting by using tools like Crystal Reports or SQL Reporting Services
- Improve front end and back end data validation
- Cleanse existing data
- Sort out invalid stuff including a way to note data that is clearly invalid and will need to be manually repaired
- Wait 12 months to build user confidence
- Add new features
- Optimize/improve interface
Questions and Answers
Q: Why would I, as an employee of a software company that makes custom-tailored and off-the-shelf software, write an article on the best way to create a new SACWIS system?
A: I am a proponent of using development Framework tools
to facilitate rapid development, which ultimately leads to project success.
Global Vision Technologies has several off-the-shelf products that
Human Services organization can buy. These products are all based on the
Visions Server development framework, which allows for off-the-shelf and custom products to be created. If I were to create a SACWIS system using the steps above, our development Framework would allow us to do so much faster than using raw Java or .Net.
Q: Why would someone trust a list that I created when our company hasn’t ever created a SACWIS system?
A: In regards to trusting the list that I have created, I post it with the desire for people to question it and try to convince me that it won’t work. I have seen millions of dollars wasted on these systems. Simply put, the current techniques don’t work well. My suggestions are not the only way to replace a legacy system, but I believe it to be the most efficient and effective way.
I am very interested in your feedback.