Old to New

OldvsNewWe have, on a number of occasions, replaced legacy software with modern client-server-web based applications. The reasons are usually simple and clear-cut.  The hardware is old and replacing it would just continue more of the same, or the software is old and incapable of modern communication capabilities. Most often, it is a combination of both that has put the client over the edge.  In one example, the client was running an older Unix based system custom written by a gentlemen now in his early 60’s.  The software still functioned but getting changes was getting more and more difficult. The client, a public warehouse and trucking operation,  knew a change was needed, so they began looking.  There are not many companies in New England that have a great deal of experience writing transportation and warehousing software. We are one of the few.

We were asked to present a plan and cost for a complete re-write and data conversion.  Legacy replacements are such difficult projects to cost out because there is so much taken for granted.  Even the best plans and forecasts come up short.  Actual cost and development time often reach 3 times what is originally budgeted.  Not withstanding, a plan and budget is always required on projects of this nature. Needless to say, in this instance, we got the bid.

So we began a projected 4 month project which ended up to be just over a year.  It was painstaking, arduous journey for both the client and us.  The client needed to remember everything they had taken for granted for so many years and we had to be open to the way memories come back in pieces.  We needed to be patient and flexible.  But more importantly, we needed to keep our goal in mind.  No custom hard coded solutions that fix problems short term, but become bottlenecks long term.  The systems needed to be data driven rather than software driven.  What that means is when our client needed a specific requirement for a particular customer, we didn’t cut corners and hard code a resolution, we added the necessary control data to have that requirement become an option for any of our clients customers.

It was imperative that we made the system custom, but generic.  Why was this so important?  Because developing software is an investment for our clients, but also for us.  We always have the tomorrow’s software in mind when we are creating today’s software.  In the past thirty years, this has proven to be a great business model.  Our clients get EXACTLY what they want, but often times, we do not need to recreate the entire wheel.  It helps us meet the commitments of our original proposal knowing that the software we create will in some ways help shape our next project and our future profitability.

In the end, our client got more than what they paid for, more than what they expected and in fact, more than what they hoped for.  The functionality of their new system is far superior to the old, far more flexible and versatile and is able to communicate with customers in ways they had never knoiwn were possible.  It has allowed them to make closer and more permanent connections to their customers which is a win-win for us, our client and their customers.