How can my multinational transition from one development platform to another?

Question

I am working in IT department of a big, international company. We are developing different Intranet applications for the business (Complaints, Rebates, Service Desk etc). Now we decided to migrate from PHP platform to .NET (integration with MS CRM Dynamics, Exchange and MS Office be among many reasons). As there are about 20 different applications the business is using on current, PHP platform, we will have to come up with the best way to move them all to the new platform. I don't want to go into details how to convert the code etc, as while we do migrate we want to improve all of these applications.

So we came up with 2 main ways of moving these apps:

1. Support just one platform. What would it mean? Create homepage and literally migrate all apps as they are to .NET (without improving them while we do that). After New intranet is running we would start rebuilding migrated applications and improving them. That would save us developing intranet in .NET while having to support PHP platform.

2. Support both platforms for some time. That would mean building just a homepage and 1 or 2 new applications (which do not exist on our PHP platform). Making these available to the users but not taking off the PHP platform (we would incorporate menus and links to make it easier for users to move between apps on PHP page and the new one). Then we would start rewriting the PHP applications while improving them.

Now I am not sure what would be better, on one hand (option 1) we will potentially make everything easier for users by not forcing them to use two different platforms at the same time. Although they won't see any improvement of having the new platform, apart from everything looking nicer, the functionality of applications on the new platform will be the same for some time. Also I think we would add ourselves (IT dep) more work as esentially we would write every app twice.
On the other hand in option two (2) users would have worse experience as two platforms look different, but they would realise the benefits of the new platform as new applications are beeing moved.

Has any of you came across something like that? What would you choose? Or maybe there is even different, better way to those I have presented? I would like to know what do you think and how would you approach that.

Answer 1

Let's consider both scenario's:

Everything-at-once migration

While you are migrating your codebase your customers will keep using your existing apps. Since migration will take a non-trivial amount of time, this means you will need to have a maintenance team on the old codebase, for bugfixing and feature development. Every change you make in the old codebase needs to happen in the new codebase. You'll end up writing every line of code twice as long as the migration isn't done, making it more expensive the longer it takes to migrate. So, it all boils down to: what will the turnaround time for the full migration be? Your development costs will skyrocket for as long as the turnaround time lasts.

Piece-by-piece migration

In this scenario you'll have better control over double effort, but you're still going to have a lot of additional costs. Your deployment will involve two separate platforms, with twice the deployment issues and additional server resources required. Unless you have a very modularly organized app, you'll find that often a piece of code is present in the other platform than the one you need it on, causing additional porting and maintenance effort. As long as the migration isn't done, your development cost will be higher. At the same time, feature pressure will mean that it's going to take you a very long time to finish migrating.

Conclusion

From personal experience I can tell you two things:

• Switching programming languages rarely pays off. From a cost-benefit analysis, it's very unlikely that it will be profitable to switch to .NET from PHP. So my main advice is: don't. Try to solve your problems with your existing codebase.
• Piece-by-piece is the best approach, but you'll have a hard time doing it on the level of application modules. You'll find that you're going to have to develop and maintain features on both side of the architecture for as long as the migration isn't fully done. It can be a good idea to prioritize features not based on what customers need most but on what will limit the amount of double effort (thereby lowering cost).

Answer 2

For financial reason, most companies I have worked went with the second approach, rightfully I might add. It takes a lot of money, time, and risks for them to achieve #1. User mostly would understand #2 as long as they see your progress and interaction with them. In this lean & mean economy, I doubt anybody would take #1 approach.

Answer 3

Big bang approaches are rarely constructive as far as end-users are concerned. I'd advise against it and to be honest I can't believe anyone would seriously consider it as an option given the number of applications concerned.

I'd be inclined to go with option two and handle re-works on a case by case basis. Admittedly this may take longer than approach one on paper but in reality, you're opening up a significant amount of business risk by taking approach one and I really wouldn't like to be around for the support calls on day one if there is even just one little problem at the user end.

Additionally, if the overwhelming bulk of your web services based applications are already written in php, how is the available .Net expertise?

I think either way your users are going to have to experience change, either big bang (cue lots of support calls) or piecemeal (increasing familiarity). I'm inclined to think you haven't really sized out exactly how much work is going to have to be done to go from being near completely all php to completely .Net either.

Answer 4

Firstly, I agree with everything Joeri says.

Option one is truly horrible. If you do this and don't continue support as Joeri describes, you shut down support for potentially a couple of years as far as your customer sees it. After two years they get effectively the same site with all of the same issues they've grown to know & hate for the last few years. Plus the risk that the market has changed in the interim and made the application obsolete & in need of a major revamp. Also, if you do shut down support for two years what do you think is going to happen to all of the service requests? They won't go away. At least some of your users will "go rogue" and develop mission critical systems in (probably) Access to plug the gaps in the systems you are rewriting - then you still end up supporting two platforms...

Option two means that you will be supporting both technologies for an extended period of time. This period of time will be longer than you think and you could end up with a permanently fragmented ecosystem - i.e. a significant amount of PHP code that is not economic to rewrite mixed with newer .NET code.

Push back hard against whoever is suggesting this. It will be much cheaper to write code to integrate the PHP applications with the products you suggest than to rewrite everything in .NET then integrate the rewritten code with the products, don't forget, the integration will not magically happen if you use .NET.

One more thing, take the number of lines of PHP code and put it into a COCOMO 2 tool to get an idea of how long and how many developers you will need in order to complete the rewrite.

Answer 5

You have a third option:-

Migrate the php code to your windows server and ISS (the same one as you plan to run .NET on!)

You can then add new applications in .NET (and slowly convert some older ones to .NET) while presenting your users with what looks like a single system.