Option 1, to purchase a new student system, was a path chosen by other Oregon districts, but on review MSD found these systems to be significantly behind its current SIS in functionality. In addition, the cost of such software was nearing $1,000,000. Even if MSD outsourced to another district, it still carried a heavy premium, compounded by high annual fees for life. When you added to that the cost of modifications and dependency on outside entities, the overall risk became too great.

MSD looked at option 2, remaining on the HP 3000, also known as homesteading. Brabham wasn’t convinced.

“While the system might have been viable for another 3 to 5 years, if it went bad, it could do so dramatically and in a very short period of time. Our hardware was already getting old and leaving that potential for disaster to a future administration to deal with seemed wrong. They’d end up with a multi-million dollar problem!”

The prospect of option 3, re-writing the system in house, was also daunting. MSD spent resources exploring two different re-write paths, each time realizing it would be a painful 5-7 year process – those timelines and resource pressures were simply too risky to continue pursuit of that route.

This left options 4 and 5... have a third party re-write the system in a modern language, or migrate the existing SIS system and database to run on a modern platform. Previous review of such solutions suggested costs in the seven figure price range. Regardless, MSD issued an RFP to the market and in response received multiple bids and proposals.

As expected, option 4, re-writing, turned out to be prohibitively expensive, carrying long timelines and exposing MSD to too much inherent risk. In addition, there were other major considerations such as the culture shock and learning curve facing programmers and users when attempting to implement the new system.

Option 5, Migration, could be achieved in two ways: Either emulate the HP 3000 environment on UNIX or Windows and run the existing applications on the emulator, or convert the existing source code to a modern programming language to run in a native open systems environment without proprietary middleware. The problem with the emulation option was that it would have left MSD bound by the restrictions of the proprietary HP3000 environment AND inherently dependent upon the vendor of the emulation software going forward, a situation MSD definitely did not want to get into given that emulation by definition is a ‘dying’ industry. Also, emulation wasn’t cheap!

The option to convert the code to run in a native open systems environment, made much more sense to Brabham.

“Our Student System was highly customized," he said, "so we liked the idea of being able to continue development after migration using .NET-compliant modern languages. UNICON would automatically convert all our source, job files and data to run in native Windows, targeting .NET and SQL Server, leaving us full ownership of our programs and in a position to further develop leveraging modern technologies.”