2009-11-06 #1

Reasons not to 'Port'

I was asked to join in the writing of Migrating to Solaris OS (c) 2003 due to some of the projects I had worked in. We argued that there were four basic techniques available,

• retirement,
• emulation
• source code engineering
• reverse engineering

Retirement is fairly obvious, but its unusual that you can retire the whole of an application. Emulation ranges from black box language emulators such as BASIC or PICK, or more modern and comprehensive interpretive solutions such as a DBMS, web container or even a complete COTS package. This technique relies on the guarantees of the vendor/author, but is an excellent and cost effective method of migrating between operating systems and hence between hardware platforms and architectures. The latter two techniques can be used to migrate the business logic at higher levels of abstraction, between, say two database implementations or 4GLs.

In my experience there are two huge inhibitors from moving.

• cost of labour intensive projects is high, particularly if using 3rd party people
• and the code/business logic is insufficiently worth preserving.

If one starts with a blank piece of paper, the opportunity to increase the business alignment of the application, increase the functionality, and reduce the maintenance cost of the application outweighs the costs of a migration. Businesses choose to rewrite the application. It also often aligns with the personal and team goals of the applications development/maintenance teams. (They stay in work & get new toys and skills).

Over the 12 years I worked at Sun, I was involved in two software migration projects, both of them from one operating system to another using emulation techniques, one of which acted as the basis for Chapter 11 of the book. I also worked on proposing two reverse engineering projects from one database vendor to another, both of which were rejected on cost grounds. (The customers stayed with their then current technology vendors). This inertia will get worse as hardware capital and maintenance costs fall both relatively and absolutley. Potential savings in the cost of platform also decrease. N.B. To most large companies, the marginal cost of licensing a database is zero, and having a support contract with a multi-billion dollar company very attractive. This trends mean that the cost of the personell cost of software increases as a proportion of the total cost and re-writing for maintenance becomes more and more attractive, since the best savings come from long term improvements in software engineering productivity.