Una migración correcta termina con el negocio funcionando de forma verificada sobre la nueva base. El cliente debe saber qué se trasladó, dónde están los datos y quién opera el servicio. Cambiar lenguaje sin esto mantiene la dependencia del proveedor. Tratamos la migración como un cambio controlado con alcance, aceptación y retirada del entorno anterior.
Definir qué se migra
Registramos páginas, administración, API, horarios e integraciones. Cada componente se traslada, sustituye o retira. Incluimos exportaciones, correos, cuentas internas e importaciones invisibles para visitantes. «Migración completa» se convierte en una especificación verificable y evita mantener funciones sin usuarios ni responsables.
Confirmamos titulares de dominio, infraestructura, código y cuentas externas. Resolvemos recursos del proveedor anterior antes de publicar. Los secretos se transmiten por un canal acordado, no en documentación abierta. El cliente conoce permisos temporales y cuándo revocarlos tras la entrega o cambios de personal.
Definir criterios de aceptación
«Todo como antes» no basta. Elegimos escenarios: solicitud recibida, publicación editorial, usuario limitado a sus registros. Definimos éxito y error. Los cálculos necesitan ejemplos. La aceptación por escenarios detecta diferencias y distingue defectos de capacidades nuevas fuera de alcance.
| Documento o resultado | Utilidad para el cliente |
|---|---|
| Inventario funcional | Confirma alcance |
| Mapa de datos | Explica almacenamiento y relaciones |
| Escenarios de aceptación | Demuestran preparación |
| Plan de cambio | Define acciones y responsables |
| Instrucciones operativas | Permiten mantenimiento |
Separar pruebas y producción
Construimos aparte. Usamos datos de prueba o adecuadamente anonimizados si no hacen falta registros reales. Limitamos administración y exposición de interfaces internas. La configuración sigue un mecanismo definido. Así el despliegue puede repetirse sin depender de un servidor montado accidentalmente con cambios manuales desconocidos.
Las comprobaciones dependen del riesgo: un catálogo y un cargo financiero necesitan atención distinta. Verificamos cadenas críticas y estado final, incluidos fallos externos y repeticiones. La transferencia y conciliación se prueban aparte. Documentamos acción, resultado esperado y observado de forma comprensible.
Preparar el cambio
Acordamos ventana, sincronización y condición de reversión. Identificamos decisores y restricciones temporales. Las escrituras entre exportación y cambio requieren tratamiento. DNS no traslada pedidos ni impide todos los accesos antiguos. El plan debe corresponder al servicio y los mecanismos reales de tráfico.
- Alcance y titulares → Criterios de aceptación
- Criterios de aceptación → Migración de prueba
- Migración de prueba → ¿Conciliación correcta?
- ¿Conciliación correcta? → Migración de prueba (No)
- ¿Conciliación correcta? → Cambio (Sí)
- Cambio → Aceptación y retirada de PHP
La reversión merece igual atención. Los registros nuevos deben conservarse; a veces conviene pausar antes que volver a una base desactualizada. Definimos errores admisibles y quién decide. En sistemas complejos un ensayo mide duración y corrige instrucciones antes del cambio real.
Quién decide que está listo
Cada fase tiene responsable del proveedor y del cliente. Desarrollo confirma comprobaciones técnicas; negocio verifica resultados. Contabilidad o almacén participan en sus escenarios. La apariencia no demuestra preparación. Antes del cambio establecemos quién puede detenerlo y a quién comunicar bloqueos.
Clasificamos comentarios por impacto. Importe o permisos incorrectos impiden publicar; una animación nueva puede esperar. Registramos decisiones para evitar expectativas verbales contradictorias. Conservamos excepciones acordadas si alguna función sigue temporalmente en el entorno anterior.
Durante la transición debe quedar claro cuál es la fuente válida de información. Una importación de prueba no autoriza a dos sistemas a modificar los mismos registros independientemente. Antes de sincronizar identificamos dónde se aceptan operaciones nuevas y cómo se conservan. Aunque la apariencia no cambie, puede llegar un pedido entre dos pasos técnicos correctos.
Las instrucciones deben servir a una persona que no haya construido el proyecto. Incluyen publicación, configuración y recuperación sin insertar secretos abiertos. Repetir el procedimiento es la prueba de transferencia, no solo recibir un enlace al repositorio.
También dejamos explícitas condiciones de mantenimiento y defectos. Así el propietario no depende de acuerdos verbales sobre duración del seguimiento o qué constituye trabajo adicional. Cuando otra persona asuma el proyecto, podrá identificar componentes, accesos y tareas sin rehacer toda la investigación inicial. La retirada de la instalación anterior se confirma con esos datos, no simplemente porque el nuevo dominio responda.
Completar la transición
Después revisamos direcciones de reserva, tareas y paneles. Quitar un enlace de WordPress no desactiva la aplicación. Si PHP sigue siendo necesario, documentamos excepción y siguiente paso. La retirada completa se verifica en el entorno activo. Los archivos antiguos tienen plazo y acceso limitado para no convertirse en fuentes incontroladas de datos o credenciales válidas.
La entrega incluye código, compilación, configuración y copias. Asignamos actualizaciones y contacto para problemas, con condiciones de defectos y soporte documentadas. Otro equipo debe poder asumir el proyecto sin reconstruir cada decisión. Un sitio que solo una persona comprende no constituye una entrega completa.
Envía descripción y restricciones de plazo. Prepararemos secuencia y presupuesto, con cuestiones previas. Los sitios sencillos permiten cambios rápidos; servicios complejos necesitan plan propio. En ambos casos verificamos funciones, datos, operación comprensible y ausencia de dependencias antiguas inadvertidas.
Fuentes
OWASP Top 10:2025. WordPress: seguridad. Revisado el 26 de octubre de 2026. Los procedimientos, ejemplos, precios y plazos describen el servicio propuesto por el proyecto.
