La portación es un término de uso muy amplio. Generalmente significa adaptar un gran bloque de código a otra cosa. Lo contrario de «portar» es «reescribir». Así que, la parte importante del proceso de portar es que estás tratando de ahorrarte mucho tiempo cuando quieres mover tu código.
Recordando que es muy poco específico, y ese es el problema con un término que se usa tan ampliamente en nuestra profesión. Así que vamos a concretar:
Digamos que he escrito un juego en C++ destinado a teléfonos Android. Funciona muy bien y se hace popular, por lo que recibo peticiones para el mismo juego en los teléfonos de Apple. Ahora tengo un par de opciones. Podría reescribir el juego desde cero utilizando las herramientas de desarrollo de Apple, o podría intentar portar mi código a Apple. Tengo que analizar la cantidad de trabajo que supone cada una de estas opciones y tomar una decisión sobre cuál de ellas me costará menos dinero a la vez que me proporciona una nueva fuente de ingresos en los teléfonos de Apple. Si decido dar soporte a los teléfonos basados en Windows, tendré la misma elección.
La adaptación puede ser un proceso muy sencillo (por ejemplo, si me muevo de una tecnología de chip a otra, pero manteniéndome en el mismo sistema operativo, podría ser tan fácil como conseguir un compilador cruzado y arreglar los errores que puedan surgir), o podría ser un proceso muy difícil.
La adaptación entre dos entornos completamente no relacionados, como el escritorio de Windows a Android Phone, tiene varios obstáculos que hay que superar. En primer lugar, las interfaces de usuario de estos dos son muy diferentes y muchas de las suposiciones que su aplicación hace cuando se ejecuta en el escritorio de Windows son completamente inválidas en un teléfono (no necesito entrar en detalles aquí, ¿verdad? las diferencias son obvias).
En segundo lugar, las herramientas son muy diferentes (los compiladores, instaladores, cadenas de distribución, etc.) por lo que es probable que haya una curva de aprendizaje para portar entre cualquier dos entornos muy diferentes. Es posible que incluso se contrate a todo un grupo de desarrolladores que entiendan específicamente el nuevo entorno para que ayuden a comprender los problemas (o incluso a un especialista en portabilidad).
En tercer lugar, hay que gestionar las limitaciones físicas de la ejecución en un teléfono (menos memoria, pantalla más pequeña, sin ratón, soporte parcial de teclado).
Muchas empresas que han tomado esta decisión han decidido que reescribir la aplicación para el nuevo entorno es la forma más barata de hacerlo. A menudo pueden tomar un núcleo de la aplicación y convertirlo en API remotas o en bibliotecas distribuibles (lo que significa que han extraído una parte más pequeña y han portado sólo eso) y luego reescribir el resto de la aplicación (por ejemplo, un juego puede extraer su motor de física en una biblioteca, pero reescribir todo el código de la interfaz de usuario).
La portabilidad es un asunto tan importante que hay empresas que se ganan la vida proporcionando un entorno de amortiguación bajo el que se escribe la aplicación. Se han tomado la molestia de crear un entorno que pueden garantizar (dentro de ciertos límites) que su aplicación se ejecutará esencialmente sin cambios en un conjunto determinado de plataformas (incluso a través de aquellos tan diferentes como los que he propuesto anteriormente). Estos entornos siempre van a ser un compromiso y a menudo implicarán limitaciones muy específicas para tu aplicación (aquellas cosas que no pueden ser implementadas o simuladas en todas las plataformas soportadas). Si puedes vivir dentro de esos límites, esos entornos pueden ser estupendos, pero si luchas con las limitaciones pueden ser una pesadilla.