将IIS / ASP.NET站点移植到LAMP？
I run technology for a medium sized company that is about to acquire another medium sized company. Our technology is all LAMP (Linux/Apache/MySQL/PHP), the company we are acquiring is all Microsoft stack (IIS/MSSQL/ASP.NET). None of the developers on staff currently do .NET nor have ever supported Microsoft server infrastructure. I'm having a tough time deciding what to do with the situation...
Do we port all the MS stuff to LAMP (not interested in going the other way for various reasons including my team's personal inexperience with it, the cost of licensing when we are trying to slash overhead, etc)?
Do we run both technologies in parallel with separate teams to support each and write a bunch of middleware so they can talk to each other?
Neither of these choices are optimal. Has anyone ever been faced with a situation like this and how did you proceed? Keep in mind we are talking about large infrastructure in both cases with high traffic volumes and fairly extensive backend systems. Any ideas will be welcomed.
我为一家即将收购另一家中型公司的中型公司运营技术。 我们的技术都是LAMP（Linux / Apache / MySQL / PHP），我们收购的公司都是微软堆栈（IIS / MSSQL / ASP.NET）。 工作人员当前都没有.NET，也没有支持Microsoft服务器基础架构。 我很难决定如何应对这种情况... p>
我们是否将所有MS内容移植到LAMP（由于各种原因（包括我的原因）不想进入其他方式 团队对它的个人经验不足，当我们试图削减开销时的许可成本等等）？ p>
我们是否与不同的团队并行运行这两种技术来支持每一项并编写一堆 中间件，以便他们可以互相交谈？ p>
这些选择都不是最佳选择。 有没有人遇到过这样的情况，你是怎么进行的？ 请记住，我们在谈论大型基础设施，包括高流量和相当广泛的后端系统。 任何想法都会受到欢迎。 p> div>
As part of the acquisition, are your company taking on the IT support team of the acquisition?
While eventually there are likely to be 'efficiency savings' that they'll want to make from consolidating back office staff, there is a strong argument to keep both teams supporting their 'own' systems in order to keep the lights on.
Then you need to analyse the overlap - do you end up with systems on each stack doing similar things. If so, look to consolidate onto the preferred platform and remove the other. Also look at (regardless of current skills), which stack best needs the business needs in the coming years. LAMP might be perfect right now, but there may be arguments for moving to .net to meet future needs. Then again maybe not, but needs to be assessed.
Is there a business need for the 2 sets of systems to share data? If so, at what level? Creating (web)services to encapsulate shared functionality and make it available to the other system may be one way to go (SOA effectively). Alternately you may need to share a backend initially and have .NET talking to a MySQL databases or somesuch.
This is a very complicated question.
If the two applications provide similar functionality, then I would run both side by side until the one you want to keep has all of the functionality of the other one. Then I'd switch the customers over and eventually throw it away. If the customers are receptive, switch them now.
If they are radically different apps then I'd most likely just maintain both going forward. Given that these are large applications, any rewrite is going to be painful and have a high probability of failure. It's best to just get used to the idea of having different tech stacks in house.
One thing, by maintaining both apps you will be in a better position to keep the acquisition as quiet as possible as far as the client base is concerned. Clients that already use an app typically only change horses if they feel the app they are using is no longer going to be supported. At that point, you can guarantee that some will leave regardless of how good the other system is.
If the acquisition is going to result in a change in marketing (for example, the other company's logo changes etc) then I would again suggest to just maintain both. The clients are going to be nervous enough as it is.
The point of all the above is that this is more of a business problem than a tech issue and boils down to the reasons you acquired the other company in the first place and how you will present it to the existing clients. If the company was acquired for the technology or their client base, then leaving it alone is a good idea.
BTW, I've done this a couple times. The only difference was going the other route from PHP to .Net.
In one case the app was relatively small, but had a huge base of users. We ended up using some URL rewriting rules so that the user base never even knew the app changed underneath them. It was a collection of web services.
In another case, the app was large, had a big user base, and had a very public skin. Again, we heavily leveraged url rewriting to preserve google placement as well as bookmarks. The biggest problem we had was development on the original site couldn't stop while we built the replacement. This presented a lot of challenges in that every feature had to go through both teams. In the end, the project took about 3 times longer than expected but because we had some highly skilled people on it it ultimately succeeded.
I've never done this before, so take my opinion with a grain of salt. But I would suggest NOT rewriting an existing application. I mean, if it's a 1-page application which just tells you "Hello" when you click a button, then yes, rewrite it in PHP. But business applications that make money aren't as simple as that, and you'll be starting from scratch to rewrite something that took the other company x years to develop. Not to mention you'll have to support and maintain the application you're taking over, even while you rewrite it in PHP.
If you have smart developers on your team now, and they have capacity, they'll be able to learn ASP .NET. But it might be best to hire some ASP .NET resources to help your team learn it and bear the weight (maintenance and support) of the application you're taking over. Your teams can work together to find integration points between the two applications.
Faced with the choice of writing integration points, or writing an entire business application from scratch, I'd take my chances at writing integration points.