Por Thomas Cohen, fundador de Maestro
Firebase Studio y GitHub Spark: preparar la continuidad de tu aplicación
El cierre de Firebase Studio no significa el fin de Firebase. Estas son las fechas oficiales, el caso distinto de Spark y un método para localizar el código, los datos y los accesos antes de cambiar de herramienta.
Tu aplicación sigue abriéndose, pero la herramienta con la que la creaste anuncia su cierre. La primera pregunta es práctica: ¿podrás corregir un problema, encontrar tus datos y publicar un cambio mañana? Antes de elegir otro asistente de IA, reúne lo que permitirá a otra persona comprender el proyecto y hacerse cargo de él.
Seguiremos a Camille, que organiza talleres, y a Noé, que la ayuda a preparar la continuidad de una herramienta de reservas. Su aplicación, sus expedientes y las comprobaciones narradas son ficticios. Esta guía combina anuncios oficiales verificados el 26 de septiembre de 2026 con un método de preparación; no describe una migración que hayamos realizado para un cliente.
1. Firebase Studio: qué cierra y qué se mantiene
Las nuevas inscripciones y la creación de espacios están bloqueadas desde el 22 de junio de 2026. Los espacios existentes cierran el 22 de marzo de 2027. Firestore, Authentication y App Hosting siguen disponibles: lo que termina es el entorno Studio. Consulta el calendario oficial.
Si ves «New user registration for Firebase Studio is currently closed», identifica primero tu situación: ¿intentabas crear una cuenta o acceder a un espacio existente? Conserva el mensaje exacto, la cuenta utilizada y la dirección del espacio. Esa información ayudará más al soporte que un simple «Firebase no funciona».
Google explica que está agrupando sus herramientas de creación con IA en torno a AI Studio y Antigravity. Los datos que queden en el espacio Studio se eliminarán cuando cierre. La guía oficial de migración detalla esta decisión. Eso no implica que tu idea de aplicación o su proceso de trabajo fueran incorrectos.
2. GitHub Spark: parte de lo que ya conservaste
GitHub retiró Spark el 31 de agosto de 2026. Su anuncio mantiene las aplicaciones ya publicadas, pero fijaba esa fecha como límite para exportar el código mediante «Create repository». Las llamadas llm() deben sustituirse. El servicio correspondiente, GitHub Models, terminó el 30 de julio.
Busca primero un repositorio o archivo comprimido ya creado. Pregunta a quien construyó la aplicación dónde está la última versión conservada. Si no encuentras nada, pide al soporte que aclare qué posibilidades quedan. No confundas una aplicación visible con unos archivos de origen recuperables; aquí no garantizamos ninguna recuperación después del plazo.
Si una función de IA ya no responde, describe cuál: redactar un mensaje, clasificar una solicitud o resumir un texto. Pide a Noé que compruebe su servicio y los accesos necesarios para sustituirlo. Reiniciar toda la construcción antes de aislar el fallo puede hacer perder tiempo e introducir nuevos errores.
3. Haz inventario de seis elementos distintos
Camille conoce la dirección de su aplicación y tiene algunas capturas. Eso ayuda a explicar su funcionamiento, pero todavía no permite ponerla en marcha en otro lugar. Con Noé, prepara una ficha por elemento. Cada ficha indica una ubicación, una persona responsable, la última comprobación y lo que falta.
- Código: archivos que definen las pantallas y el funcionamiento, con la versión que se retomará.
- Datos: reservas, datos de contacto y documentos realmente guardados.
- Cuentas: servicio de inicio de sesión y personas capaces de administrar el proyecto.
- Configuración: direcciones de servicios y credenciales confidenciales de las que depende la aplicación.
- Publicación: alojamiento, dirección pública y control del nombre de dominio.
- Gastos: suscripciones activas, consumo y persona que recibe las facturas.
Una misma cuenta puede controlar varios elementos; eso no los hace intercambiables. Camille puede pagar una suscripción sin tener el acceso necesario para modificar la aplicación. Noé puede tener el código sin poder consultar las reservas. Anota estas diferencias antes de iniciar una copia o cerrar un servicio.
4. Recupera el código y comprueba lo que has obtenido
En Firebase Studio, la ruta indicada por Google es «Move now» y después «Zip and Download». La guía de migración describe las opciones según tu proyecto. Si alguien compartió el espacio contigo, aclara con su propietario cómo exportarlo. Conserva la fecha de exportación y pide que se abra el archivo obtenido: terminar una descarga todavía no verifica su contenido.
Noé debe poder reconocer la versión esperada, encontrar el último cambio en la pantalla de reservas y explicar cómo ejecutar una copia. Camille conserva aparte una descripción del recorrido y las decisiones importantes. Si quien retoma el proyecto debe adivinar todas las reglas en una conversación antigua, el expediente sigue incompleto.
Trabaja sobre una copia. Pide que se conserven los archivos originales y que los cambios sean identificables. Si el proyecto no arranca, anota el mensaje exacto y el paso que falla. «Sustituir archivos hasta que funcione» no produce un procedimiento que puedas repetir.
5. Comprueba los datos y las cuentas por separado
El archivo del código no demuestra que las reservas tengan una copia de seguridad. Pide que se identifique dónde están guardadas, sus posibles adjuntos y el método adecuado para recuperarlas. Solicita una comprobación con ejemplos preparados para la prueba. Evita entregar datos de contacto reales a un nuevo asistente solo para ver si entiende el proyecto.
En nuestro escenario, Camille elige tres casos ficticios: una reserva confirmada, una solicitud cancelada y dos personas con el mismo nombre. Anota el resultado esperado de cada uno. Noé debe encontrar el expediente correcto, su estado y su documento. Contar tres filas no basta si los expedientes se han mezclado.
Trata también el inicio de sesión como una cuestión distinta. Una lista de clientes no contiene necesariamente lo que permite acceder a sus cuentas. Pide que se comprueben las cuentas existentes, la creación de una nueva, la recuperación del acceso y los permisos. Cambiar la interfaz sin probar estos recorridos puede dejar a los usuarios ante una puerta cerrada.
La guía de migración de datos ayuda a preparar una correspondencia y un informe de prueba. Si los datos siguen en el mismo servicio, déjalo escrito: trasladar la herramienta de desarrollo no obliga a trasladar toda la información. Esa decisión debe confirmarse en tu proyecto real.
6. Localiza las credenciales, el dominio y los gastos
Noé hace inventario de los servicios necesarios sin copiar sus secretos en una ficha pública. Una clave de acceso a un servicio debe gestionarse en el lugar seguro previsto para ella, con una persona capaz de sustituirla. Pregunta qué accesos necesitará el nuevo entorno y cómo limitar su alcance. Encontrar un valor en un archivo no es una invitación a difundirlo.
Camille comprueba quién controla el dominio y el alojamiento. Pregunta qué cambiará para el visitante: dirección, inicio de sesión, correos recibidos o enlaces ya compartidos. Antes de trasladar la dirección pública, pide que se revisen los ajustes que dependen de ella. Una pantalla accesible en una dirección de prueba no demuestra que las confirmaciones llegarán a los clientes.
Respecto a los gastos, enumera los servicios que siguen siendo de pago y su utilidad. ¿Quién controla el consumo del nuevo proveedor de IA? ¿Qué suscripción puede seguir siendo necesaria durante la prueba? ¿En qué condiciones se detendrá la anterior? Espera a verificarlo antes de eliminar un servicio que todavía pueda guardar datos o mantener la aplicación en funcionamiento.
7. Elige una vía de continuidad que alguien pueda mantener
Camille compara las posibilidades con un cambio limitado: añadir un campo opcional a una solicitud, conservar las reservas antiguas y publicar la corrección en un entorno de prueba. Observa qué debe instalar, explicar o corregir Noé. Ese trabajo da una base más útil que el número de herramientas de una página comparativa.
La elección debe concretar dónde se conservará el código, quién podrá modificarlo y cómo se publicará una nueva versión. Pregunta también qué necesitará saber la siguiente persona para tomar el relevo. Si todo depende de una cuenta personal inaccesible o de una operación que nadie anotó, la continuidad sigue siendo frágil.
Un presupuesto útil separa el diagnóstico, las adaptaciones, la recuperación de datos, las pruebas y la puesta en marcha. Identifica las incógnitas antes de prometer un precio total. La propiedad y continuidad del proyecto afectan tanto a los derechos y accesos como a los archivos copiados.
8. Realiza una prueba completa con resultados esperados
Prepara un entorno donde las pruebas no envíen mensajes a clientes reales ni modifiquen las reservas utilizadas a diario. Camille y Noé indican los datos ficticios que usarán y lo que debe desactivarse o sustituirse para la prueba. Pide que se confirme esa separación antes del primer clic.
- Una persona autorizada inicia sesión y encuentra solo los expedientes previstos para ella.
- Una nueva reserva conserva su fecha y estado después de cerrar y volver a abrir.
- Una cancelación libera la plaza correcta sin borrar las demás reservas.
- Un adjunto se abre en el expediente correcto y sigue siendo inaccesible para una cuenta no autorizada.
- Una función de IA produce un resultado comprobable; su fallo muestra un mensaje comprensible.
- Un cambio del código puede publicarse de nuevo desde los archivos entregados.
Para cada prueba, anota la fecha, la persona, el resultado esperado, el observado y la evidencia conservada. En nuestro ejemplo, una confirmación visible no equivale a recibir el correo. Camille comprueba también el buzón de prueba. Una respuesta tranquilizadora del agente no sustituye esa observación.
Después de corregir algo, repite las comprobaciones afectadas y un recorrido completo. Si el inicio de sesión solo funciona con la cuenta de Noé, el trabajo no está terminado para Camille. Haz revisar los aspectos técnicos y los permisos por una persona competente; las pruebas del trabajo cotidiano no cubren todos los riesgos.
9. Prepara el cambio y una posible vuelta atrás
Decide qué sistema será la referencia durante la transición. Si la aplicación anterior sigue recibiendo reservas, explica cómo se recuperarán después del cambio. Una copia hecha el lunes no contiene automáticamente las solicitudes del martes. Designa a la persona que comprobará los nuevos registros antes de autorizar el cambio.
El plan de vuelta atrás debe indicar la versión que se pondrá de nuevo en servicio, los datos que se conservarán y las acciones necesarias. Pide que se ensaye el procedimiento sobre una copia. Volver a un código anterior no recupera necesariamente las reservas nuevas, y una copia de seguridad antigua puede borrar cambios recientes si se utiliza sin preparación.
Fija también los motivos para detenerse: expedientes ausentes, acceso incorrecto, confirmación no recibida o imposibilidad de publicar una corrección. Prevé quién decide y quién puede intervenir. Camille no hace el cambio porque se acerque la fecha; lo hace cuando se cumplen las condiciones acordadas y el equipo sabe cómo actuar ante un problema.
10. Termina con una decisión y responsables concretos
¿Hay que reconstruirlo todo? No antes de averiguar qué falta. Un acceso perdido, una función de IA que hay que sustituir y un código que no arranca son tres problemas distintos. Pide que se presupuesten los trabajos realmente necesarios. Si aún desconoces el estado del proyecto, empieza por un diagnóstico limitado con un resultado escrito.
¿Puedes continuar con Maestro? Somos los creadores de Maestro, que ayuda a dirigir la construcción o continuidad de un proyecto con agentes de IA desde un Mac. No garantiza una migración automática de Studio o Spark. La compatibilidad, los datos y la publicación deben examinarse y probarse; ninguna captura de demostración acredita la continuidad de tu aplicación.
Los archivos del proyecto permanecen en tu equipo, con posibles intercambios con proveedores de IA, como explica nuestra página sobre datos. La beta es gratuita por invitación; el consumo de IA y los gastos de funcionamiento de tu aplicación deben presupuestarse aparte. Elige esta vía solo si alguien puede comprender y mantener el resultado.
Antes de terminar, Camille completa su ficha: código comprobado, datos localizados, accesos probados, publicación repetida, gastos identificados y vuelta atrás preparada. Cada línea tiene un responsable y una evidencia, o una pregunta abierta. Ese expediente permite decidir el siguiente paso, sea cual sea la herramienta elegida.