El proyecto más frustrante que tuve el año pasado fue migrar una tienda online de una plataforma a otra. No porque la migración fuera técnicamente difícil — sino porque no debería haber sido necesaria.
El cliente había pagado por un desarrollo en una plataforma que no servía para lo que necesitaba. El desarrollador anterior eligió la herramienta que él conocía, no la que el proyecto requería. Resultado: 8 meses de desarrollo, un sitio que no podía hacer lo que el negocio necesitaba, y un costo de migración que casi igualó al desarrollo original.
Este error es más común de lo que pensás. Y es el más caro, porque no se arregla con un parche — se arregla rehaciendo.
Casos reales que me llegaron
Tienda con 2.000 productos en una plataforma de landing pages. El proveedor anterior usó un website builder (de esos de arrastrar y soltar) para hacer una tienda online. Funcionó con 20 productos. Con 2.000, el sitio tardaba 30 segundos en cargar y el panel de administración era inutilizable. Hubo que migrar todo a WooCommerce desde cero.
Sistema de gestión en WordPress con 14 plugins. Un negocio necesitaba un sistema con login de usuarios, roles, dashboards personalizados, y reportes. El desarrollador lo armó todo con plugins de WordPress: un plugin de membresías, uno de formularios avanzados, uno de reportes, uno de roles, uno de acceso restringido. Catorce plugins para hacer lo que un sistema a medida hace con código limpio. El sitio se rompía con cada actualización.
Blog corporativo en un framework de JavaScript. Una empresa quería un blog con buen SEO. El desarrollador lo hizo en React con server-side rendering. Técnicamente impecable. Pero cada vez que el equipo de marketing quería publicar un artículo, necesitaba un desarrollador que pusiera el contenido en el código y deployara. Para un blog, WordPress hubiera sido la opción correcta — permitiendo que marketing publique sin depender de nadie.
Por qué pasa
El desarrollador solo conoce una herramienta
Es el caso más frecuente. Un desarrollador que solo sabe WordPress mete todo en WordPress, aunque el proyecto necesite otra cosa. Un desarrollador que solo sabe React hace todo en React, aunque sea un sitio de cinco páginas que no necesita JavaScript.
La herramienta correcta depende del problema, no de las habilidades del desarrollador.
El cliente pide la herramienta en vez del resultado
“Quiero un sitio en WordPress” no es un brief — es una prescripción. El brief correcto es “necesito un sitio donde pueda publicar contenido, administrar un catálogo de 200 productos, y que cargue rápido”. A partir de ahí, el desarrollador recomienda la herramienta que mejor resuelve esos requisitos.
Cuando el cliente llega con la herramienta decidida de antemano, muchas veces viene de un consejo mal dado o de algo que leyó en internet sin contexto.
Nadie evaluó alternativas
El presupuesto se acepta y el proyecto arranca sin una conversación previa sobre qué tecnología conviene y por qué. Esa conversación de 30 minutos puede ahorrarte meses de frustración y miles de dólares en migración.
Cómo elegir bien
Empezá por el problema, no por la solución
¿Qué necesita tu proyecto? Listá las funcionalidades concretas:
- ¿Necesitás editar contenido sin tocar código? → CMS (WordPress, Astro con un headless CMS)
- ¿Necesitás vender productos online? → eCommerce (WooCommerce, Shopify, o desarrollo a medida si la lógica es compleja)
- ¿Necesitás un sistema con login, roles, y lógica interna? → Desarrollo a medida
- ¿Necesitás un sitio rápido que casi no cambie? → Generador estático (Astro, Next.js)
Preguntale al desarrollador por qué
“¿Por qué recomendás esta tecnología para mi proyecto?” Si la respuesta no incluye tus requisitos específicos, es una señal de que está recomendando lo que conoce, no lo que necesitás.
Pensá a 2-3 años
Tu negocio va a crecer. ¿La plataforma que elegís hoy puede acompañar ese crecimiento? Si hoy tenés 50 productos pero en dos años vas a tener 500, la plataforma necesita soportar eso sin rehacerla.
Pedí una segunda opinión
Antes de firmar un presupuesto de desarrollo, invertí en una consultoría de stack. Una evaluación independiente de qué tecnología conviene para tu proyecto, sin compromiso de que la misma persona lo desarrolle. Esas dos horas de consulta pueden ahorrarte el costo de una migración futura.
El costo real de migrar
Migrar un sitio de una plataforma a otra cuesta, en el mejor de los casos, el 50% del desarrollo original. En el peor (cuando hay datos complejos, integraciones, y SEO que preservar), puede costar más que el desarrollo original.
Sumar a eso:
- Tiempo de inactividad o funcionamiento degradado durante la transición
- Riesgo de pérdida de posicionamiento en Google si la migración de URLs no se hace bien
- Horas de re-capacitación del equipo en la nueva plataforma
- Estrés acumulado de toda la operación
Todo eso se evita con una decisión correcta al inicio.