在 Unix 世界中，「可移植性」指的是移植到不同的 Unix 版本。對於 GNU 程式而言，這種可移植性是理想的，但不是最重要的。
GNU 軟體的主要目的是作為 GNU 作業系統的一部分運行，使用 GNU 編譯器在各種硬體類型上編譯。因此，絕對必要的可移植性種類相當有限。重要的是要支援基於 Linux 的 GNU 系統，因為它們是人們主要使用的 GNU 形式。
使 GNU 程式在 GNU 系統以外的作業系統上運行，並不是開發 GNU 套件的核心目標之一。你永遠不必這樣做。然而，使用者會要求你這樣做，並且配合這些要求是有用的——只要你不讓它主導專案或阻礙主要目標。
支援其他自由或近乎自由的作業系統（例如，*BSD）是好的。支援各種 Unix-like 系統是理想的，雖然不是最重要的。這通常不會太困難，所以你可能不妨做做看。但如果結果證明很困難，你不必將其視為義務。
在大多數情況下，將程式移植到更多平台是好的，但你不應該讓它佔用你太多時間，以至於阻礙你以更核心的方式改進程式。如果它開始這樣做，請告訴使用者你不想在這上面花更多時間——必須由其他人編寫程式碼、除錯、編寫文件等等，然後你可以安裝它。
你也可以因為技術原因拒絕移植補丁，就像對使用者提交的任何其他補丁一樣。這取決於你。
實現可移植到大多數 Unix-like 系統的最簡單方法是使用 Autoconf。你的程式不太可能需要比 Autoconf 能提供的更多關於主機平台的資訊，因為大多數需要這些知識的程式已經被編寫出來了。
當有更高等級的替代方案（readdir）時，避免使用半內部資料庫（例如，目錄）的格式。
至於不像 Unix 的系統，例如 MS-DOS、Windows、VMS、MVS 和較舊的 Macintosh 系統，支援它們通常需要大量工作。在這種情況下，最好花時間添加在 GNU 和 GNU/Linux 上有用的功能，而不是支援其他不相容的系統。
如果你支援 Windows，請不要將其縮寫為 “win”。請參閱 商標。
通常我們完整寫出名稱 “Windows”，但當簡潔非常重要時（例如在檔案名稱和一些符號名稱中），我們將其縮寫為 “w”。例如，在 GNU Emacs 中，我們在 Windows 特有檔案的檔案名稱中使用 ‘w32’，但 Windows 條件的巨集稱為 WINDOWSNT。原則上也可以有 ‘w64’。
在編譯你的 C 檔案時，定義「功能測試巨集」_GNU_SOURCE 是個好主意。當你在 GNU 或 GNU/Linux 上編譯時，這將啟用 GNU 函式庫擴充功能的宣告，如果你以其他方式在你的程式中定義相同的函式名稱，這通常會給你一個編譯器錯誤訊息。（如果你希望程式更易於移植到其他系統，你不必實際使用這些功能。）
但是，無論你是否使用這些 GNU 擴充功能，你都應該避免將它們的名稱用於任何其他含義。這樣做會使你的程式碼難以移到其他 GNU 程式中。