Publicado el 3 de junio de 2026
Las apps web progresivas (AWP) revolucionaron la Web al ofrecer experiencias similares a las de las apps. Sin embargo, una de sus mayores fortalezas también ha sido un desafío persistente: la identidad de la app está estrechamente vinculada al origen web.
Para cambiar la marca o reestructurar tu arquitectura (por ejemplo, pasar de www.example.com/social a social.example.com), te enfrentaste a un dilema doloroso.
No había forma de "mover" una PWA instalada. Los usuarios debían desinstalar manualmente la app anterior y buscar el botón de instalación de la nueva.
El equipo de AWP se complace en presentar la migración del origen de la AWP en Chrome 150. Esta nueva función de la plataforma te permite migrar sin problemas las AWP instaladas a un origen nuevo del mismo sitio con una interrupción mínima para el usuario, y, al mismo tiempo, mantenerlo suficientemente informado.
Qué permite la migración de origen
Puedes modificar la arquitectura de tu sitio sin afectar la experiencia del usuario:
- Libertad de arquitectura técnica: Cambia el subdominio o la ruta de acceso de tu aplicación.
- Se corrigieron los estados de división de la app: Se resolvió el problema por el que cambiar un
start_urlsin un ID estable creaba accidentalmente instalaciones duplicadas de la app.
Los usuarios pueden migrar sus apps con un simple diálogo de actualización. Se les informa sobre la migración de manera similar a una actualización estándar de la app. Con un solo clic, se desinstala la app anterior y se instala y se inicia la nueva.
Cómo migrar una AWP
Para migrar una PWA, sigue estos pasos. En el resto de la publicación, se explica con más detalle:
- Implementa el protocolo de enlace:
- Agrega
migrate_froma la app nueva. - Agrega el campo
allow_migrational archivo/.well-known/web-app-origin-associationen el origen anterior.
- Agrega
- Elegir comportamiento:
suggest(o vacío) evita interrumpir al usuario, lo que probablemente sea útil durante el lanzamiento inicial.forcebloquea al usuario y requiere la migración si el usuario no puede seguir usando las URLs antiguas. - Mantén actualizada la app anterior: Si el sitio anterior redirecciona al sitio nuevo, usa la propiedad
install_urlen el bloquemigrate_frompara asegurarte de que el navegador pueda seguir encontrando el manifiesto anterior para posibles actualizaciones. - Implementa
iden el manifiesto de destino: Chrome requiere que el manifiesto de la app de destino incluya un campoid. Esto garantiza que la app no cometa el error común de crear apps divididas cambiando elstart_urlsin tener unidestablecido.
El protocolo de enlace bidireccional: cómo funciona
Para garantizar la seguridad y evitar la apropiación hostil, la migración requiere un protocolo de enlace seguro entre los orígenes antiguos y nuevos. Este protocolo de enlace garantiza que ambos sitios estén controlados por la misma entidad.
Paso 1: La app nueva declara el predecesor (obligatorio)
Agrega un campo migrate_from al manifiesto de la app web de la aplicación nueva.
// Manifest at https://fileman.google.com/manifest.json
{
"name": "File Manager",
"id": "/files/",
"start_url": "/files/index.html",
....
"migrate_from": [
"https://drive.google.com/"
]
}
Paso 2: El origen anterior confirma la migración (obligatorio)
Para evitar que un sitio nuevo secuestre unilateralmente una app antigua, el origen anterior debe autorizar explícitamente la migración. Esto se hace con un archivo de configuración .well-known.
// File at https://drive.google.com/.well-known/web-app-origin-association
{
"https://fileman.google.com/files/": {
"allow_migration": true
}
}
Paso 3: Señalización proactiva (opcional)
Para activar la actualización sin esperar a que el usuario visite el sitio nuevo, actualiza el manifiesto de la app anterior para que apunte al nuevo.
// Manifest at https://drive.google.com/manifest.json
{
"name": "Drive",
"start_url": "/",
"migrate_to": {
"id": "https://fileman.google.com/files/",
"install_url": "https://fileman.google.com/drive/installwebapp?usp=migrate"
}
}
Paso 4: Controla los redireccionamientos (opcional)
Como alternativa al uso del campo migrate_to, puedes indicar la migración redireccionando las URLs de la app anterior a la nueva y confiando en que scope_extensions haga que no se muestre el banner fuera del alcance en la app anterior. Esto significa que nunca se verá el manifiesto de la app anterior y, por lo tanto, nunca se podrá actualizar. Para permitir que la app anterior siga actualizándose antes de que se produzca la migración de la app, configura install_url dentro de migrate_from para informar al navegador sobre una URL que se debe recuperar y que aún tiene adjunto el manifiesto anterior sin redireccionamiento.
// Manifest at https://fileman.google.com/manifest.json
{
"name": "File Manager",
"id": "/files/",
"start_url": "/files/index.html",
....
"migrate_from": [
{
"id": "https://drive.google.com/",
"install_url": "https://drive.google.com/drive/installwebapp?usp=migrate"
}
]
}
Eso es todo. La UX es similar a la que se usa para la actualización de apps, en la que se notifica al usuario en la esquina superior derecha de la ventana de la app:

Si haces clic en Revisar actualización de la app, se mostrará la siguiente UX (según lo que haya cambiado en el manifiesto):

Controla la experiencia del usuario
Puedes elegir la agresividad de la migración con la marca behavior:
- Sugerir (predeterminado): El usuario recibe una notificación pasiva (por ejemplo, en el menú de la app). Pueden elegir actualizar o desinstalar la app, o ignorar la migración iniciando el diálogo.
- Obligatorio: En el próximo inicio de la app, se le mostrará al usuario un diálogo de bloqueo. Debe actualizarse al nuevo origen o desinstalar la app (consulta la siguiente captura de pantalla).
En el siguiente ejemplo, se muestra cómo establecer esta opción:
"migrate_from": [
{
"id": "https://example.com/social/",
"behavior": "force" // or suggest
}
]

Conclusión
La función de migración de AWP permite a los desarrolladores seguir creando arquitecturas web modernas y flexibles sin dejar atrás a los usuarios.