將IIS / ASP.NET站點移植到LAMP？

Question

我為一家即將收購另一家中型公司的中型公司運行技術。 我們的技術全部是LAMP（Linux / Apache / MySQL / PHP），我們要收購的公司是全部Microsoft堆棧（IIS / MSSQL / ASP.NET）。 目前，沒有任何開發人員會使用.NET，也從未支持Microsoft服務器基礎結構。 我很難決定如何處理這種情況...

我們是否將所有MS東西都移植到LAMP（由於各種原因，包括我團隊的個人經驗不足，在嘗試削減開銷時的許可成本等，對以其他方式不感興趣）？

我們是否將這兩種技術與獨立的團隊並行運行以相互支持，並編寫大量中間件，以便他們可以相互交流？

這些選擇都不是最佳選擇。 有沒有人遇到過這樣的情況，您如何進行？ 請記住，在這兩種情況下，我們都在談論大型基礎架構，高流量和相當廣泛的后端系統。 任何想法都將受到歡迎。

Answer 1

我以前從未做過此事，因此請多加保留。 但是我建議不要重寫現有的應用程序。 我的意思是，如果它是一個1頁的應用程序，它在您單擊按鈕時告訴您“ Hello”，那么可以，用PHP重寫它。 但是，賺錢的業務應用程序並不是那么簡單，您將要從頭開始重寫某些東西，而這花了另一家公司x年的時間。 更不用說即使在PHP中重寫應用程序，也必須支持和維護您要接管的應用程序。

如果您現在在團隊中擁有聰明的開發人員，並且他們有能力，他們將能夠學習ASP .NET。 但是最好是租用一些ASP .NET資源來幫助您的團隊學習它，並承擔您要接管的應用程序的負擔（維護和支持）。 您的團隊可以共同努力，找到兩個應用程序之間的集成點。

面對選擇編寫集成點或從頭開始編寫整個業務應用程序的選擇，我會把握機會編寫集成點。

Answer 2

作為收購的一部分，貴公司是否要承擔收購的IT支持團隊？

雖然最終他們可能希望通過合並后台人員來實現“效率節省”，但是有強烈的理由認為，讓兩個團隊都支持自己的“自己的”系統以保持正常運轉。

然后，您需要分析重疊部分-您是否最終使每個堆棧上的系統執行相似的操作。 如果是這樣，請考慮合並到首選平台上，然后刪除另一個平台。 還要看看（不管當前的技能如何），這些技能最能滿足未來幾年的業務需求。 LAMP現在可能是完美的，但是可能會有爭論轉向.net以滿足未來的需求。 然后也許不是，但是需要進行評估。

這兩組系統共享數據是否需要業務？ 如果是這樣，在什么級別？ 創建（網絡）服務以封裝共享功能並使其可用於其他系統可能是一種方法（有效地實現SOA）。 或者，您可能最初需要共享一個后端，並讓.NET與MySQL數據庫或類似數據庫通信。

Answer 3

這是一個非常復雜的問題。

如果兩個應用程序提供相似的功能，那么我將並排運行直到您要保留的應用程序具有另一個應用程序的所有功能。 然后，我將客戶切換過來，並最終將其丟棄。 如果客戶接受，請立即切換。

如果它們是截然不同的應用程序，那么我很可能會繼續保持兩者。 鑒於這些都是大型應用程序，因此任何重寫都將是痛苦的，並且很有可能失敗。 最好只是習慣於在內部使用不同的技術堆棧的想法。

一件事，通過同時維護這兩個應用程序，您將處於一種更好的位置，可以盡可能地減少對客戶群的收購。 已經使用應用程序的客戶端通常只會在感覺不再支持使用的應用程序時換馬。 到那時，您可以保證無論另一個系統的性能如何，其中一些都會離開。

如果收購將導致市場營銷發生變化（例如，另一家公司的徽標發生變化等），那么我再次建議僅保留兩者。 客戶會很緊張。

綜上所述，這不僅僅是技術問題，更是業務問題，歸結為您首先收購另一家公司的原因以及如何將其展示給現有客戶。 如果該公司是為該技術或其客戶群而收購的，那么不理會它是一個好主意。

順便說一句，我已經做過幾次了。 唯一的不同是從PHP到.Net的另一條路。

在一種情況下，該應用程序相對較小，但是擁有大量的用戶。 我們最終使用了一些URL重寫規則，以便用戶群甚至都不知道在其下面的應用程序已更改。 它是Web服務的集合。

在另一種情況下，該應用程序很大，擁有龐大的用戶群，並且具有非常公開的外觀。 同樣，我們大量利用URL重寫來保留Google位置以及書簽。 我們遇到的最大問題是，在我們構建替代產品時，原始站點上的開發無法停止。 這就帶來了很多挑戰，因為每個功能都必須經過兩個團隊。 最終，該項目花費了比預期多三倍的時間，但是由於我們擁有一些高技能的人才，因此該項目最終獲得了成功。