Accounting for change

This is an old post, repeated once again because I'm flabbergasted by some of the practice that goes on in IT due to a recent event.

Tl;dr : You always add exit costs to the originating system.

When comparing two systems you have numerous costs including licensing, maintenance, installation, support and exit that need to be considered. In one recent example, a question of whether to upgrade a system or switch to a more open alternative, a blatant example of misappropriation occurred. The figures are provided in table 1.

Table 1 - Costs of System

Name	License / Maintenance / Support	Length of Term	Installation Costs	Cost (solution)
System A2	£3 million p.a.	5 years	£1 million	£16 million
System B	£100,000 p.a.	5 years	£20 million	£20.5 million

In the above, upgrading system A1 to system A2 (which were the same system, just the latest version) incurred a high annual license / maintenance fee but small installation costs due to similarity of the system. However, migrating to an open source system (in this case system B) whilst reducing annual fees incurred a massive installation cost due to the cost of changing systems which worked with the existing installations. Hence at first glance, the sensible thing to do is simply upgrade to System A2. 

This is woefully wrong.

Let us take Table 1, add in the exit costs and include System A1. See Table 2.

Table 2 - Costs of System

Name	License / Maintenance / Support	Length of Term	Installation Costs	Exit / Migration Cost
System A1	Unknown	Unknown	Unknown	Unknown
System A2	£3 million p.a.	5 years	£800,000	£200,000
System B	£100,000 p.a.	5 years	£300,000	£19.7 M

In the above, we have no data for the original system A1 and the majority of the costs involved in installing System B involved conversion of other systems which had previously worked with System A1. I've put this into a column Exit Costs. For System A2, the costs involved with converting other systems is lesser due to the similarities between system A1 and A2.

Now, the first thing to note is that the majority of the costs involved in System B have nothing to do with System B. Instead they're costs of moving from another solution. System B itself because it uses open standards is relatively easy to move to and from. What we're in effect doing is transferring a liability created by one set of systems (i.e. A1 / A2) to another (B) which makes the latter more unattractive. It's a bit like someone saying that because Wind power is replacing nuclear that wind power should absorb the costs of nuclear decommissioning. Only in the world of IT does this accounting slight of hand seem to work.

What should happen is exit costs should be applied to the originating system. Now, if we adjust this taking into consideration the cost of transferring an open standards system B to an equivalent and how use of any system will create continued and increasing exit costs then we get to something like table 3.

Table 3 - Cost of System

Name	License / Maintenance / Support	Length of Term	Installation Costs	Exit Cost (upgrade)	Exit Cost (migration)	Cost (solution)
System A1	Unknown	Unknown	Unknown	Unknown	£19.7 million	Unknown
System A2	£3 million p.a.	5 years	£800,000	£200,000	> £19.7 million	> £35.7 million
System B	£100,000 p.a.	5 years	£300,000	£100,000	> £100,000	> £1 million

In the above, the cost of upgrading from A1 to A2 incurs the exit cost of upgrade, the license / maintenance and support fees and the installation costs. The long term liability (exit cost) to another system is continued and in effect will only increase.

Migrating from system A1 to B will incur low costs of license / maintenance and support but also a longer term lower liability of exit cost since system B uses open standards. We can estimate a cost of upgrade from one open standards based solution to another and I've added a figure for this. 

The total cost of solution B is vastly lower than upgrading to system A2. The only reason why it didn't appear so in the first instance is we transferred an originally unaccounted liability associated with exit from system A1 and discounted it from the upgrade path of A1 to A2 by adding it to the migration path of A1 to B. The only thing that will happen in this circumstance is you will become further locked into the vendor of system A1 / A2 and your future liability will just increase.

By forcing such exit costs to be calculated and added to the originating project, you also force vendors to attempt to reduce your exit costs by including more open data, open standards efforts. If you don't do this and allow exit costs to be misapplied then you only create incentives for vendors to lock-in you in further.

Yes, in terms of cash the cost of implementing System B will be more expensive but that's only because those who installed System A1 didn't account for the exit costs. We learned these lessons a long time ago. 

If you're still adding liabilities from exit costs to the wrong project (usually disguised as costs of migration / transition to) then :-

1) Please, never, ever run a piece of critical national infrastructure. 

2) Please go find someone to help run your IT for you. It'll save you money long term if you consider exit costs in purchasing.

Every single IT project creates a future liability, a cost of exit. When someone tells you that you can't move to a more open system (i.e. open data formats etc) because the cost of migration is too high then this normally means someone hasn't been doing their job and accounting for, managing and mitigating against this future liability.