Honestly, changing your platform is an incredibly difficult and expensive proposition. Ultimately, it is a business decision that should be governed by numbers:
Revenue / company savings from applications developed internally [the more the application makes or saves your company, the more migration probably makes sense]
Size and average salary of telent pool
Developer turnover rate
Cost (time) to hire replacement [resently, it has been impossible to hire good Java talent in the valley, FYI]
Cost of stability / performance of current platform [performance and stability come into this equation. Remember, Friendster sucked because it was sloooooww as hell, before they transitioned to PHP]
Productivity gains of new platform to current platform [this is a guess, but, I people can agree, Ruby developers are generally more productive developing web applications than a C programmer]
Available frameworks / maturity [the newest platforms aren't the most valuable IMHO
How long will it take to migrate [this one is key, and probably impossible to get absolutely correct. Error on the high side, and software project ALWAYS takes longer than expected IMHO]
You should be able to mush these numbers together to get a better sense if migrating makes sense. A company of mine recently changed from a Perl to a Java implementation of a client product. It turned out to be the right call for many reasons: performance, talent pool, maintainability, available libraries, and client perception [a lot of people think a Java application is more "enterprise ready" than a Perl one]
All that said, also consider:
Can you migrate to the new platform piecemeal [if you have 1 developer, you don't wan to lose all his time while he migrates your platform]
You WILL have bugs [and probably the same bugs you worked out when you implemented the system the first time]
Web Services, XML, and other standards that allow different code to talk to eachother is probably going to be your friend during this migration
Slashdot Mirror
- Revenue / company savings from applications developed internally [the more the application makes or saves your company, the more migration probably makes sense]
- Size and average salary of telent pool
- Developer turnover rate
- Cost (time) to hire replacement [resently, it has been impossible to hire good Java talent in the valley, FYI]
- Cost of stability / performance of current platform [performance and stability come into this equation. Remember, Friendster sucked because it was sloooooww as hell, before they transitioned to PHP]
- Productivity gains of new platform to current platform [this is a guess, but, I people can agree, Ruby developers are generally more productive developing web applications than a C programmer]
- Available frameworks / maturity [the newest platforms aren't the most valuable IMHO
- How long will it take to migrate [this one is key, and probably impossible to get absolutely correct. Error on the high side, and software project ALWAYS takes longer than expected IMHO]
You should be able to mush these numbers together to get a better sense if migrating makes sense. A company of mine recently changed from a Perl to a Java implementation of a client product. It turned out to be the right call for many reasons: performance, talent pool, maintainability, available libraries, and client perception [a lot of people think a Java application is more "enterprise ready" than a Perl one] All that said, also consider:- Can you migrate to the new platform piecemeal [if you have 1 developer, you don't wan to lose all his time while he migrates your platform]
- You WILL have bugs [and probably the same bugs you worked out when you implemented the system the first time]
- Web Services, XML, and other standards that allow different code to talk to eachother is probably going to be your friend during this migration
Good luck! Hope this helped!