Cuánto tarda migrar tu sitio a Webflow: 4 semanas o 8

Cuatro semanas si es una migración. Ocho si además es un rediseño. La plataforma casi no mueve ese número.

La pregunta llega siempre con una fecha adentro. Alguien pidió el sitio nuevo para el evento de octubre, y en realidad no te interesa cuánto tarda: te interesa si llega.

Te cuento qué pasa dentro de cada plazo, y por qué la fecha casi nunca la define el proveedor.

¿Cuánto tarda, entonces?

Cuatro semanas una migración. Ocho un rediseño. Son nuestros plazos, y antes de defenderlos conviene separar las dos palabras, porque la mayoría de las consultas las usa como sinónimos.

Migración es mover el mismo sitio de una plataforma a otra. Uno a uno. De WordPress a Webflow, o de Webflow a Astro con Sanity. El diseño no se discute: se traslada.

Rediseño es otra cosa. Adentro entran estrategia, workshop, definiciones de negocio, mensaje, copy, diseño, y recién al final el desarrollo. El cambio de plataforma viaja de colado.

Para ubicarte, los rangos que publica el mercado para 2026 van de 4 a 6 semanas un sitio chico y hasta 12 a 20 un proyecto enterprise. Nuestros números entran en la parte baja por una razón poco glamorosa: somos un equipo chico y no hay cadena de mandos interna que aprobar.

Así que la primera pregunta no es cuántas semanas. Es cuál de los dos proyectos estás comprando.

¿Por qué una migración entra en cuatro semanas?

Porque no queda ninguna decisión por tomar. El diseño existe, el contenido existe, la estructura existe. El trabajo es de ejecución.

Eso no quiere decir que sea liviano, ni mucho menos: adentro de esas cuatro semanas hay un inventario completo de URLs, un mapeo uno a uno de las viejas a las nuevas, los 301 implementados y un crawl posterior para confirmar que no quedó nada colgado.

Hay además una capa que nadie ve y que es la que evita el desastre: la arquitectura de CMS, la estructura de links internos, el structured data y el QA de formularios e integraciones. De eso hablamos largo en la nota sobre migrar sin perder SEO.

Una migración rápida no es una migración a medias. Es una migración donde nadie está decidiendo cosas sobre la marcha.

¿Y si tu sitio ya tiene autoridad ganada?

Entonces hay una capa más, y no entra adentro de las cuatro semanas: las rodea.

Un sitio que viene publicando hace años acumula algo que no se muda con el contenido: posiciones, links que apuntan a URLs específicas, páginas que Google ya sabe para qué búsqueda mostrar. Eso es un activo. Y es el único del proyecto que se puede perder de un día para el otro sin que nadie lo note hasta que llega el reporte del mes siguiente.

Por eso, cuando el sitio tiene tráfico orgánico que importa, la migración deja de ser un trabajo de mudanza y se convierte en cinco frentes en paralelo.

• Medición antes, durante y después: keyword research, identificación de rankings y un reporte pre y post migración. Sin esa foto previa no hay forma de saber si perdiste, porque no tenés contra qué comparar.
• Análisis competitivo: quién compite por tus mismas búsquedas y qué los rankea. Lanzar sin ese contexto es lanzar a ciegas.
• Arquitectura e indexación: estructura de páginas, links internos, URLs, sitemap y robots. Sin esto, páginas clave pueden tardar semanas en indexar.

Después viene la optimización semántica, que es asegurarse de que cada página le siga señalando a Google por qué búsqueda es relevante: titles, descriptions, jerarquía de headings, semántica del HTML. Se toca todo al migrar y es donde más fácil se rompe algo sin darse cuenta.

Y queda el mapeo de redirects, que es el paso crítico: auditoría completa de URLs, mapeo uno a uno, 301 implementados y un crawl posterior. Si eso sale mal, la historia de rankings desaparece de un día para el otro.

El detalle de cronograma es este: la medición previa arranca antes del kickoff y el monitoreo sigue semanas después de publicar. O sea que el proyecto termina cuando el tráfico se estabiliza, no el día que apretás publish. Si tu sitio no tiene autoridad que perder, esta capa no te hace falta y no deberías pagarla.

¿En qué se van las ocho semanas de un rediseño?

En casi todo lo que pasa antes de que alguien abra Figma.

Un rediseño arranca con estrategia y sigue con el workshop, que es donde aparecen de a poco las definiciones de negocio que nadie había escrito todavía: a quién le vendés, con qué argumento, por qué te eligen a vos y no al otro. De ahí sale el mensaje, y del mensaje sale el copy. Recién entonces se diseña.

Por eso el diseño se lleva la mayor parte del plazo. Es la parte más artesanal del proceso y es donde se agrega el valor que después vas a ver todos los días. No se acelera sin bajar la calidad, y bajar la calidad ahí es exactamente lo contrario de lo que fuiste a buscar.

El desarrollo en Webflow, al lado, es la parte predecible. Se estima bien y se cumple.

Y ahí está lo que más sorprende cuando lo decís en voz alta: en un rediseño, el cambio de plataforma es anecdótico. Nadie contrata ocho semanas para mudarse de WordPress. Las contrata por el sitio nuevo, y la mudanza viene incluida.

Esto también explica el número del presupuesto. Sumar el rediseño encarece entre 40% y 80%, según los rangos que ya desglosamos acá. No es un recargo: es otro proyecto adentro del proyecto.

¿Qué estira un cronograma de verdad?

Vos. Y lo digo sin reproche, porque del lado técnico el reloj es bastante aburrido: se estima y se cumple.

En una migración uno a uno esto casi no pasa, porque no hay nada que aprobar. En un rediseño pasa una y otra vez, y casi siempre por los mismos tres lugares:

• Feedback que tarda: la ronda de revisión que se agenda para la semana que viene y termina siendo dentro de tres.
• Stakeholders sin alinear: tres personas opinan distinto y el proyecto queda esperando a que se pongan de acuerdo entre ellas.
• Material que no llega: fotos, textos, accesos, el logo en vectorial que estaba en la computadora de alguien que ya no trabaja ahí.

Y queda el cuarto, que es el más caro de todos: el change request en etapa avanzada. Un cambio pedido en la semana seis no cuesta lo que cuesta ese cambio, cuesta todo lo que obliga a rehacer de lo que ya estaba aprobado, más la conversación para explicar por qué se movió la fecha. Esto no es hipotético.

Ninguna de las cuatro es culpa de la herramienta. Por eso cambiar de agencia rara vez arregla el cronograma.

¿Qué podés hacer para que entre en fecha?

Tres cosas, y las tres se hacen antes de firmar.

Definí quién aprueba. Una persona, no un comité. Puede consultar a quien quiera, pero la que dice "va" tiene que ser una sola.

Juntá el material antes del kickoff. Cada hora que tu equipo dedica a ordenar textos, fotos y accesos antes de arrancar es una hora que después no le cuesta al cronograma, y no la cotiza nadie.

Y acordá hasta qué semana se aceptan cambios sin mover la fecha. Esta es la que nadie escribe y la que más fechas salva. Si la conversación incomoda hoy, imaginate en la semana seis.

¿Y después de publicar?

El proyecto no termina el día que sale. Termina cuando tu equipo puede manejarlo solo.

Por eso el training va siempre incluido, sin excepción: si terminás dependiendo de nosotros para cambiar un título, hicimos mal el trabajo. Sumamos 30 días de garantía como mínimo en todos los proyectos, y soporte continuo solo en los casos en que el cliente lo necesita de verdad, no como una cuota que se cobra de gusto.

Contá esas semanas también cuando armes tu calendario interno.

Lo que se pregunta cuando ya hay una fecha prometida

Estas son las que aparecen apenas alguien pone el plazo en un calendario compartido. Si te falta una, mandala y la sumamos.

La fecha no la define la plataforma

Antes de pedir presupuestos, decidí cuál de los dos proyectos necesitás. Migrar y rediseñar son cosas distintas, cuestan distinto y tardan distinto, y mezclarlas en el pedido es la forma más rápida de recibir tres cotizaciones que no se pueden comparar.

Ya sé lo que pasa: la fecha no la elegiste vos, te la dieron. Entonces la pregunta cambia. No es cuánto tarda, es qué versión entra. Una migración uno a uno entra en cuatro semanas y te deja el rediseño para después, con calma y sin volver a cambiar de plataforma.

Si querés que miremos tu sitio y te digamos cuál de los dos necesitás, escribinos. Te vamos a dar el plazo real, incluso si la respuesta es que no hace falta migrar nada.