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.

  • 1
    Isn't #2 a step to #1? Aug 19, 2011 at 13:55
  • No, these are 2 different things. In 1 we would migrate the whole of the intranet before allowing users to use it and then we would work on improving apps. In 2 we would migrate the essential part of the intranet, allow users to use it, and then start migrating other apps and improving them while we migrate...
    – Daniel Gruszczyk
    Aug 19, 2011 at 13:58
  • @greengit : read the topic, integration with other, business critical applications is one of the reasons. My question is not treating about 'Why to migrate' though, but 'How to migrate'. Aug 31, 2011 at 9:54
  • I read the topic & had the same question. I doubt very much whether the project could ever be cost justifiable. Can you tell us the name of the company so we can short-sell it? ;)
    – mcottle
    Aug 31, 2011 at 12:53
  • haha, I don't care about costs to be honest as I am just an IT student on a work placement with the company. I am just asking for my own knowledge... Apperently my manager justified the costs enough to have the go-ahead from CEO... Aug 31, 2011 at 13:04

5 Answers 5


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.


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).
  • You have made very intresting points. Although it is not up to myself if we switch the platform or not, and I will be working for the company only untill the end of september (I am with them on a uni work placement). Switching from PHP to .NET might be a good idea though since the old PHP framework we have would need some MAJOR works, databases aswell, the system the company uses at the moment is OLD and created by people who did not have great developement skills... Aug 31, 2011 at 13:09
  • Also my question would be: Is 'change freeze' on old platform a good idea? What I mean by that is that any changes to existing systems on PHP platform, other than bug fixes, are frozen until we start moving given application to .NET . That is my manager's part of the plan for the migration... Sep 2, 2011 at 8:48
  • If this is a non-trivial system it's highly unlikely that a change freeze will work in practice. If someone really needs a feature, they'll escalate it to a higher level than your manager, and you'll be forced to make changes. Also, bugfixes by themselves can take up a sizable amount of team resources. And always keep in mind that old systems have seen a lot of tweaking, and new designs are likely to forget all those little one-line fixes, which will need to happen all over again for users to accept the redesigned product. Sep 2, 2011 at 10:56
  • One more point: if the system is going to be rebuilt, what safe-guards are in place to ensure better code quality this time around? I've seen an application that was rewritten 4 times because of platform and code quality issues. Sep 2, 2011 at 10:59

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.

  • That was exactly my thought. My manager wants to go ahead with #1, which I find difficult to understand.
    – Daniel Gruszczyk
    Aug 19, 2011 at 15:05

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.

  • I guess it is more complicated than just supporting two seperate platforms or not. Either way is not really good approach... Thanks for your time! Aug 31, 2011 at 13:54

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.

  • Good point. What would you do then, if it wasn't up to you if you migrate the system or not. Which approach would you choose? Or mybe is there another approach to them I have listed? If your manager wouldn't agree with you, would you try to prove that your approach is better? Aug 31, 2011 at 13:53
  • Write the PHP applications in a more layered "Service Oriented" way. Use an enterprise service bus to buffer the interface between PHP & Microsoft land. The key thing is do the COCOMO estimation, that should scare the living rewrites out of your manager.
    – mcottle
    Aug 31, 2011 at 14:00

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.

  • PHP indeed runs under IIS
    – Bart
    Sep 4, 2011 at 15:51

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.