總的來說，微軟在更新每個操作系統版本的時候，都盡量保持向前的兼容性。但是也有一些例外，如果一系列為提升性能所做的更新要兼顧之前版本就會影響整體性能時就無法一改而論了。舉個例子，微軟之前移除了對15位應用的兼容支持。
Windows 8的客戶端及服務器版本有很多更新將帶來兼容性方面的巨大挑戰。這些新挑戰中的一部分沒法由管理員來解決，它們只能由應用的初始開發者處理。
大多數變更在稱為“windows和windows server開發者預覽兼容手冊”的更新文檔中都有解釋，它對大多數程序兼容性問題都有詳細說明，對當前版本存在的問題提供了解決方案。
以下是幾個已知的程序兼容性故障報告。
系統版本數字。是的，老問題又以新的面貌出現了。因為windows采用特殊的版本號，一些老的應用程序可能會因此出現問題，Windows 8為自己定義的版本號是6.2。這些程序可以用當前windows提供的兼容模式來運行(例如，在程序快捷方式的兼容性頁中)，但是如果你是一個程序開發者，你就必須更加小心確認版本號碼。微軟建議小心使用‘檢查版本信息’功能(用大於、不等於或者一個特殊的版本號)。
無頭的服務器應用。這是最重要的幾個變化之一，因為新版windows server(主要是server core)的設計不單運行無頭程序，還要支持那些沒有圖形界面的程序。在性能較差的環境中圖形界面可以卸載(例如，在資源被廣泛分享的虛擬機中)，或者出於其它原因，比如減少服務器被攻擊可能性的考慮也可以進行類似操作。
一些服務器程序，盡管它們可能並不在無圖形界面環境中運行。任何命令行版本應用理論上都應該運行得很好，但是一旦它被用圖形界面呈現給用戶之後就可能無法很好地運行了。現在沒有很好的辦法來解決這個圖形界面引起的問題，所以它在大多數時候僅能保持無圖形界面版本的應用。
如果你准備在server core版本操作系統上運行所有應用，那麼你應當充分測試來確認它在無圖形界面環境下能如期望般表現良好。如果結果相反，同時如果你對程序編寫有一定了解，那麼你需要將現有的代碼遷移到server core平台下，並且重新確認那些WIN32 API和.NET CLR能被core系統所支持。
.NET框架。Windows 8將.NET 4.5框架放進它默認程序安裝包中，但是並不包含.NET3.5。如果你有一些程序明確只支持3.5版本，不僅僅是獨立的程序，還有那些基於該版本.NET的網站程序，這種情況下你需要手動地添加老版的.NET。幸運的是，這不會引起大的兼容性問題，因為不同版本的.NET可以並存獨立運行。微軟文檔有一些說明，介紹了如何在不觸動windows更新情況下手動地添加.NET 3.5框架。
因為.NET4.5已經是windows run time(WinRT)的一部分，Word允許開發者用“metro“視圖創建應用，並可用沙漏程序模型迅速創建程序。如果你想要為Windows 8更改或者升級服務器應用，並且你已經了解C#或者C++，那麼這個任務並不困難，但是文檔中還是有一些值得探索的東西。
4K磁盤扇區。這個說來更像是一個硬件問題，而不是程序問題，但是它仍然值得我們注意。目前市場上主流的新磁盤一般使用4K扇區替代舊的512字節扇區設計。4K扇區驅動器，也就是所謂“高級格式”磁盤，在為512字節扇區設計的程序上經常會出現一些奇怪的問題。它沒有很好地考慮向前兼容的問題。Windows 8增加了一個新的API，用來查詢文件扇區大小，然後用命令行工具支持腳本查詢卷大小。
沒有簽名的內核驅動。如果你有一些程序，不管是第三方的或者是廠商自帶的，使用到內核驅動，windows server出於安全考慮嚴格限制對內核驅動的使用，並將其視為流氓軟件。對設備使用內核驅動最大的變化包括標准擴展固件接口(UEFI)安全啟動功能，它用於保護機器免受流氓軟件攻擊。UEFI安全啟動是服務器的可選項，不過建議啟用它。如果你想在服務器上使用UEFI安全啟動項，你最好用可信任的證書來為內核驅動做驗證。否則，建議禁用安全啟動項。
