WordPress almacena gran parte de su contenido visible mediante un conjunto reducido de estructuras centrales reutilizables, pero esas estructuras pueden sustentar aplicaciones muy distintas. Un registro de la tabla de posts puede representar un Blog Post, una CMS Page, un archivo adjunto multimedia, un elemento de navegación, una revisión o un tipo de contenido personalizado. Una taxonomía puede clasificar contenido editorial, registros de directorios, cursos, eventos o Products. Los metadatos pueden ser un simple valor de presentación o el campo que conecta un registro con un plugin, una plantilla, una regla de permisos o un sistema externo.
Por tanto, la decisión importante de la migración no es si un valor puede entrar en WordPress, sino qué objeto de WordPress debe ser su propietario y qué relaciones hacen que el registro pueda gestionarse correctamente. Una “página” de la plataforma de origen puede convertirse en una CMS Page, un tipo de contenido personalizado, un archivo de taxonomía, un registro de plugin o varios objetos vinculados. Un “cliente” de origen puede convertirse en un usuario de WordPress, un Customer de un plugin de comercio, un perfil de membresía, un contacto de CRM o no requerir ninguna cuenta de WordPress.
El núcleo de WordPress ofrece tipos de registro reutilizables, no un único esquema empresarial universal
El núcleo de WordPress separa contenido, clasificación, medios, identidad, configuración, comentarios, enrutamiento y presentación. Los plugins pueden registrar nuevos tipos de contenido o crear tablas independientes para aplicaciones especializadas. Los temas y las plantillas de bloques determinan la presentación, pero no se convierten automáticamente en propietarios de los registros empresariales subyacentes.
| Capa de WordPress | Significado en el núcleo | Consecuencia para la migración |
|---|---|---|
| Tabla de posts | Almacena varios tipos de contenido, incluidos Posts, Pages, archivos adjuntos, revisiones, elementos de menú y tipos de contenido personalizados registrados | El tipo de contenido y sus relaciones importan más que el hecho de compartir una misma tabla. |
| Taxonomías y términos | Clasifican registros mediante vocabularios jerárquicos o planos | Una Category de origen no puede mapearse de forma segura sin saber qué clasifica y cómo la utiliza el destino. |
| Metadatos | Añaden datos de clave-valor a posts, usuarios, términos y comentarios | El mismo patrón de almacenamiento puede contener campos de presentación, relaciones, permisos, estado de plugins o identificadores externos. |
| Usuarios, roles y capacidades | Representan identidad y autorización | Un usuario de WordPress no es automáticamente un Customer, miembro, alumno, donante, vendedor o perfil de personal. |
| Opciones y ajustes | Almacenan configuración del sitio o de plugins | Los registros de configuración no deben confundirse con entidades de contenido portables. |
| Comentarios | Almacenan interacciones asociadas a posts u otros objetos compatibles | Los comentarios de Blog Posts, reseñas de Products, testimonios, preguntas y debates pueden necesitar propietarios distintos en el destino. |
| Plugins y tablas personalizadas | Añaden registros y funcionamiento específicos de cada dominio | Comercio, membresías, formularios, eventos, directorios, aprendizaje y reservas requieren una interpretación según su propietario. |
WordPress puede recibir muchos tipos de datos de origen, pero el modelo de destino debe definir el tipo de contenido previsto, la taxonomía, el propietario de los metadatos, el propietario del plugin y la ruta. Sin esas decisiones, el contenido migrado puede existir en la base de datos y, aun así, no aparecer en el editor, los archivos, las plantillas, la búsqueda, los permisos o el flujo de trabajo de la aplicación.
Los Blog Posts, las CMS Pages y los tipos de contenido personalizados representan significados de contenido distintos
Los Posts y Pages de WordPress comparten el almacenamiento central, pero cumplen funciones editoriales distintas. Los Blog Posts suelen formar parte de un flujo de publicación fechado y pueden participar en Categories, etiquetas, autoría, archivos, feeds y navegación cronológica. Las CMS Pages suelen representar contenido relativamente estable del sitio y pueden formar jerarquías padre-hijo. Los tipos de contenido personalizados modelan dominios estructurados que van más allá del contenido editorial convencional.
Una plataforma de origen puede llamar “página” a todos sus registros públicos aunque estos representen eventos, ubicaciones, casos de estudio, recursos, personal, cursos, propiedades o listados. Convertirlos todos en CMS Pages elimina el límite de tipo que permite disponer de campos, archivos, filtros, plantillas y administración especializados.
| Registro de origen | Posible destino en WordPress | Relación que determina la elección |
|---|---|---|
| Artículo de noticias o entrada editorial | Blog Post | Fecha de publicación, autor, Categories, etiquetas, archivos, feeds y contenido relacionado |
| Página de información, contacto, políticas o servicios | CMS Page | Jerarquía estable, ubicación en el menú, plantilla de página y ruta |
| Evento | Tipo de contenido personalizado de eventos o registro de eventos propiedad de un plugin | Fecha, lugar, organizador, recurrencia, venta de entradas y relaciones con el calendario |
| Propiedad o listado de directorio | Tipo de contenido personalizado de listados o registro de un plugin de directorio | Ubicación, atributos, filtros de taxonomía, propietario, estado y relaciones de búsqueda |
| Curso o lección | Tipo de contenido y tablas relacionadas propiedad del LMS | Jerarquía del curso, inscripción, progreso, cuestionarios, certificados y reglas de acceso |
| Product | Modelo de Product del plugin de comercio | Tipo de Product, variación, precio, stock, impuestos, envío y relaciones con Customers y Orders |
| Sección de diseño reutilizable | Patrón de bloques, parte de plantilla, registro del constructor o bloques insertados | Reutilización de presentación, no identidad editorial independiente |
Los tipos de contenido personalizados pueden almacenarse junto con otros tipos de contenido, pero compartir almacenamiento no los hace intercambiables. Sus capacidades registradas, funciones admitidas en el editor, taxonomías, metadatos, exposición REST, comportamiento de archivo y plantillas determinan cómo los utilizan editores y aplicaciones.
Taxonomías, términos, menús y archivos están relacionados, pero no son intercambiables
Las taxonomías de WordPress clasifican objetos. Las Categories son jerárquicas de forma predeterminada, las etiquetas son planas, y los plugins o temas pueden registrar taxonomías personalizadas para dominios como temas, marcas, ubicaciones, sectores, tipos de recursos, niveles de cursos o atributos de Products. Los términos son los valores individuales contenidos en esas taxonomías.
Los menús y la navegación son estructuras separadas. Una entrada de menú puede enlazar a una CMS Page, un Blog Post, un archivo de taxonomía, un archivo de tipo de contenido personalizado, una URL externa u otra ruta. La existencia de un término de taxonomía no garantiza una entrada de menú correspondiente, y la jerarquía del menú no reproduce necesariamente la jerarquía del contenido.
| Estructura de origen | Propiedad en WordPress | Aspecto que debe resolverse en la migración |
|---|---|---|
| Sección editorial | Category o taxonomía personalizada | Conservar la relación con los tipos de contenido correctos y el comportamiento de archivo previsto. |
| Etiqueta de palabra clave | Etiqueta o taxonomía personalizada plana | Evitar crear una jerarquía profunda cuando el valor de origen solo es una anotación. |
| Marca, región o tipo de recurso | Taxonomía personalizada, taxonomía de comercio o clasificación de plugin | Mantener vocabularios separados cuando controlan filtros o plantillas diferentes. |
| Árbol principal de navegación | Registros de navegación/menú | El orden y el anidamiento del menú son relaciones de presentación, no pertenencia a una taxonomía. |
| Landing page de una clasificación | Archivo de taxonomía, CMS Page o vista de plugin | Decidir qué objeto es propietario de la ruta, el cuerpo del contenido y el conjunto de resultados filtrados. |
| Category de origen utilizada solo internamente | Metadatos o clasificación externa | No exponer de forma predeterminada un código operativo como archivo público de WordPress. |
Las relaciones entre términos también requieren contexto. Un término asignado a Blog Posts puede compartir etiqueta con otro asignado a Products, pero ambos pueden pertenecer a taxonomías distintas y servir a aplicaciones diferentes. Combinarlos únicamente porque sus nombres coinciden puede mezclar archivos y filtros que no guardan relación entre sí.
Los metadatos y los campos personalizados pueden contener datos de presentación, relaciones o estado de la aplicación
Las API de metadatos de WordPress admiten valores adicionales para posts, usuarios, términos y comentarios. Los plugins y temas utilizan habitualmente metadatos para subtítulos, valores SEO, identificadores externos, elecciones de plantilla, referencias de archivos, ubicaciones, fechas, precios, ajustes de visibilidad, identificadores de relaciones y estado serializado de aplicaciones.
El patrón de almacenamiento por sí solo no revela el significado. Una meta key puede contener un valor de texto simple, una referencia a otro post, una lista de identificadores de términos, un identificador de archivo adjunto, una matriz estructurada o una máquina de estados específica de un plugin. Un campo que se muestra correctamente en el origen puede quedar inutilizable si el destino copia solo el valor literal y pierde la definición del campo o el objeto referenciado.
| Patrón de metadatos | Posible significado | Requisito en el destino |
|---|---|---|
| Texto simple o número | Subtítulo, especificación, fecha, puntuación, código o etiqueta editorial | Asociar el valor al objeto correcto y exponerlo mediante la interfaz de edición prevista. |
| ID de post o archivo adjunto | Relación con otro registro o elemento multimedia | Traducir la referencia al registro de destino en lugar de copiar el antiguo ID numérico. |
| ID de término | Relación de clasificación | Volver a conectar el valor con la taxonomía y el término del destino. |
| ID de usuario | Autor, propietario, instructor, vendedor, revisor o responsable | Conservar el rol empresarial, no solo el número de usuario del origen. |
| Matriz serializada o JSON | Campos repetidores, diseños, ajustes, coordenadas o estado de plugin | Interpretar el esquema del plugin propietario antes de decidir si la estructura sigue siendo portable. |
| Identificador externo | Clave de CRM, ERP, PIM, DAM o sistema heredado | Mantenerlo estable en la entidad de destino que representa el mismo objeto empresarial. |
Las definiciones de los campos pueden ser tan importantes como sus valores. Los sistemas que registran campos personalizados pueden definir tipo de campo, valores permitidos, etiquetas de presentación, reglas de entrada, repetidores, grupos, lógica condicional y relaciones. Copiar los valores sin sus definiciones puede dejar a los administradores con datos que ningún editor o plantilla sabe utilizar.
Los bloques, constructores, plantillas y datos del tema pertenecen a la capa de presentación
El contenido de WordPress puede representarse como HTML del editor clásico, marcado de bloques, shortcodes, estructuras específicas de un constructor, bloques reutilizables, patrones, partes de plantilla o ajustes del tema. Estas capas pueden hacer referencia a la misma CMS Page o al mismo tipo de contenido personalizado subyacente y, al mismo tiempo, codificar la presentación de formas distintas.
Un constructor de páginas del origen puede almacenar datos de diseño en post_content, metadatos, tipos de contenido personalizados, opciones o tablas personalizadas. Un sitio basado en bloques puede almacenar los bloques de contenido en el registro mientras el Site Editor y el tema proporcionan las plantillas que lo rodean. El modelo de destino debe mantener separada la propiedad del contenido de la propiedad de la presentación.
| Estructura de presentación | Qué controla | Qué permanece separado |
|---|---|---|
| Bloques del núcleo dentro del contenido del post | Contenido estructurado y atributos de bloques de un registro | Plantillas de todo el sitio, navegación, datos de plugins y registros externos |
| Shortcodes | Instrucciones de marcador interpretadas por un plugin o tema | La configuración real del plugin o los datos consultados por el shortcode |
| Diseño de un constructor de páginas | Secciones, widgets, estilos y referencias específicos del constructor | Los registros empresariales mostrados dentro del diseño |
| Plantilla o parte de plantilla | Estructura de representación de todo el sitio | Datos de CMS Pages, Blog Posts, Products, Customers u Orders |
| Opción del tema | Ajuste global de diseño o visualización | Contenido editorial portable y registros de aplicaciones |
| Bloque o patrón reutilizable | Contenido de presentación reutilizable | Cada instancia o entidad empresarial mostrada a través del patrón |
El destino no necesita conservar el formato de almacenamiento interno de un constructor del origen cuando utiliza otro sistema de representación. Sí necesita conservar el contenido, los archivos multimedia, los enlaces, las relaciones reutilizables y la propiedad de los registros que requiere la nueva implementación.
Los archivos multimedia son registros con archivos, metadatos y relaciones padre
Los medios de WordPress no son solo un directorio de archivos copiados. Los elementos multimedia pueden ser registros de archivos adjuntos con títulos, pies de foto, descripciones, texto alternativo, tipos MIME, metadatos del archivo, tamaños de imagen, autoría, fechas y relaciones padre. Los cuerpos de contenido, los metadatos de imagen destacada, las galerías, los bloques, los campos de plugins y los sistemas externos pueden hacer referencia a esos archivos adjuntos.
| Situación de medios en el origen | Representación en WordPress | Consecuencia de la relación |
|---|---|---|
| Imagen destacada | Archivo adjunto más relación de imagen destacada con un registro de contenido | Tanto el archivo como la referencia deben migrarse correctamente. |
| Imagen insertada en contenido | Archivo adjunto o archivo externo más URL dentro del contenido | El contenido de destino debe apuntar a la ubicación correcta del archivo. |
| Galería | Varios archivos adjuntos más una estructura de bloque, shortcode, constructor o plugin | Transferir los archivos por sí solo no conserva el orden, los pies de foto ni el comportamiento de la galería. |
| Documento descargable | Archivo adjunto, URL de archivo o descarga propiedad de un plugin | Las reglas de acceso, los destinos de los enlaces y las rutas de sustitución siguen formando parte del modelo. |
| Imagen de Product o listado | Archivo adjunto relacionado mediante un plugin de comercio o directorio | La relación del plugin es distinta del uso multimedia ordinario de una CMS Page. |
| Recurso alojado externamente | URL remota o referencia DAM | El destino debe conservar el propietario externo en lugar de inventar una relación con un archivo adjunto local. |
Los ID padre de los archivos adjuntos no siempre constituyen un mapa completo de propiedad. Una misma imagen puede aparecer en varios registros, y los flujos de trabajo más recientes del editor pueden no establecer un padre significativo. El destino debe derivar las relaciones de las referencias reales, los campos de imagen destacada, las galerías, los registros de plugins y el marcado del contenido, en lugar de depender únicamente de la columna de padre.
Usuarios, roles, capacidades y perfiles representan significados de cuenta diferentes
Los usuarios de WordPress proporcionan la identidad de inicio de sesión, mientras que los roles y capacidades definen las acciones permitidas. Los metadatos de usuario añaden valores de perfil y estado específico de plugins. Los plugins pueden introducir membresías, cursos, comunidades, cuentas de comercio, perfiles de vendedores, directorios de personal, suscripciones o relaciones con contenido protegido.
| Identidad de origen | Posible representación en WordPress | Distinción de propiedad |
|---|---|---|
| Autor o editor | Usuario de WordPress con autoría y capacidades editoriales | La propiedad del contenido y el historial de revisiones pueden importar independientemente del estado de inicio de sesión. |
| Administrador del sitio | Usuario con capacidades administrativas | La autoridad administrativa no equivale a ser Customer o miembro. |
| Suscriptor de newsletter | Contacto de marketing externo, registro de plugin o usuario limitado de WordPress | El consentimiento de marketing y la pertenencia a una lista no deben inferirse a partir de una cuenta de inicio de sesión. |
| Miembro | Usuario de WordPress más perfil, plan, acceso y registros de estado de un plugin de membresía | El registro de usuario por sí solo no reproduce el funcionamiento de la membresía. |
| Alumno | Usuario de WordPress más inscripción, progreso, cuestionarios y certificados de un LMS | El historial de aprendizaje pertenece al dominio del LMS. |
| Customer | Customer de un plugin de comercio, usuario de WordPress, identidad de compra como invitado o contacto de CRM externo | La propiedad del ámbito comercial debe definirse explícitamente. |
| Vendedor o vendedor de marketplace | Usuario más registros de vendedor y pagos propiedad del plugin | La pertenencia a un rol por sí sola no representa la cuenta comercial completa. |
Los hashes de contraseñas del origen, proveedores de autenticación, configuraciones multifactor e identidades de inicio de sesión único pueden no ser portables como campos de usuario ordinarios. La cuenta puede conservar su identidad empresarial aunque la relación de autenticación tenga que representarse de otra manera.
Los comentarios, las revisiones y los registros históricos necesitan su propio contexto
Los comentarios pueden representar conversación de blog, reseñas de Products, testimonios, preguntas, mensajes de soporte o interacciones de plugins. Las revisiones representan versiones anteriores del contenido, no registros públicos independientes. Los autoguardados, los estados de papelera, los posts programados y los posts privados también tienen significado dentro del ciclo de vida.
| Registro histórico | Significado en WordPress | Límite de la migración |
|---|---|---|
| Comentario de blog | Interacción asociada a un Blog Post o una CMS Page | Conservar autor, fecha, estado, respuesta padre y relación con el contenido propietario. |
| Reseña de Product | Registro similar a un comentario, propiedad de un plugin de comercio | La valoración, el estado de propietario verificado, la referencia al Product y el significado de moderación difieren de un comentario ordinario. |
| Debate con hilos | Jerarquía de comentarios o registro de plugin de comunidad | Las respuestas padre-hijo y el contexto de membresía pueden ser esenciales. |
| Revisión de contenido | Versión histórica de un post | No presentar las revisiones como CMS Pages o Blog Posts públicos duplicados. |
| Registro en borrador, programado, privado o en papelera | Estado del ciclo de vida de una entidad de contenido | El estado de publicación debe seguir siendo distinto de la visibilidad en menús y de los permisos de acceso. |
Los registros históricos pueden excluirse deliberadamente cuando ya no aportan valor empresarial, pero no deben confundirse de forma silenciosa con el contenido actual. El modelo de destino debe indicar si representa el registro actual, su historial editorial o ambos.
Los plugins y las tablas personalizadas definen una propiedad específica de cada aplicación
Los plugins de WordPress pueden registrar tipos de contenido personalizados, taxonomías, metadatos, roles, endpoints REST, ajustes y eventos programados. También pueden crear tablas de base de datos dedicadas cuando el dominio requiere estructuras que no encajan en los patrones centrales de posts y metadatos. Formularios, reservas, membresías, sistemas de aprendizaje, eventos, directorios, donaciones, redirecciones, analítica, automatización y comercio suelen añadir sus propios registros.
| Área propiedad de un plugin | Registros que pueden existir | Requisito de migración |
|---|---|---|
| Formularios | Definiciones de formularios, campos, envíos, notificaciones e integraciones externas | Separar la estructura reutilizable del formulario de los datos históricos enviados y de los flujos de entrega. |
| Membresías | Planes, suscripciones, reglas de acceso, relaciones con usuarios y contenido protegido | Mantener separadas la identidad, los derechos de acceso, el pago y la propiedad del acceso al contenido. |
| Sistemas de aprendizaje | Cursos, lecciones, inscripciones, progreso, cuestionarios, intentos y certificados | Conservar las relaciones que exige el modelo de aprendizaje del destino. |
| Eventos y reservas | Eventos, sesiones, recursos, asistentes, reservas, pagos y recordatorios | No reducir los horarios y las relaciones de reserva a posts genéricos. |
| Directorios o marketplaces | Listados, propietarios, ubicaciones, atributos, reclamaciones, vendedores y pagos | Identificar qué registros son contenido y cuáles pertenecen al flujo de trabajo de la aplicación. |
| SEO y redirecciones | Metadatos, valores canónicos, campos de schema, redirecciones y vistas previas sociales | Asociar los valores al registro propietario de la ruta correcto y mantener separados los ajustes globales del sitio. |
| Tablas personalizadas | Entidades a medida, historiales, relaciones, registros y claves de integración | Traducir el esquema empresarial en lugar de copiar filas de tablas sin su aplicación propietaria. |
Los nombres de archivo de los plugins y las listas de estado activo no constituyen el modelo de datos. El verdadero mapa de propiedad procede de los tipos de contenido registrados, taxonomías, claves de metadatos, tablas personalizadas, roles de usuario, opciones, eventos programados y referencias externas utilizados por el sitio.
Las URL, los permalinks, los archivos y el alcance Multisite forman parte de la identidad del registro
Las rutas de WordPress pueden depender del tipo de contenido, slug, Page padre, fecha de publicación, Category, taxonomía personalizada, configuración de archivos, reglas de reescritura, dominio del sitio y endpoints de plugins. Por tanto, una URL de origen no siempre puede reconstruirse únicamente a partir del título del destino.
| Elemento de ruta | Relación del registro | Implicación en el destino |
|---|---|---|
| Ruta de CMS Page | Slug de la Page más jerarquía padre | Mover la Page bajo un padre distinto puede cambiar la ruta completa. |
| Permalink de Blog Post | Slug del post más patrón de permalink configurado | Los segmentos de fecha o Category pueden formar parte de la URL histórica. |
| Archivo de taxonomía | Regla de reescritura de la taxonomía y slug del término | Un término puede ser propietario de un archivo público aunque no tenga ninguna entrada de menú. |
| Archivo de tipo de contenido personalizado | Regla de reescritura y configuración de archivo del tipo de contenido registrado | Las rutas de registro individual y de archivo pueden necesitar identidades separadas. |
| Endpoint de plugin | Ruta de aplicación asociada a una cuenta, Product, curso u otra área | El endpoint no es una CMS Page ordinaria. |
| URL de Multisite | Alcance de red, sitio, dominio y ruta | Los registros pueden pertenecer a un sitio mientras los usuarios o plugins mantienen relaciones en toda la red. |
| Redirección | Relación entre ruta antigua y nuevo destino | La ruta anterior sigue siendo un registro de continuidad aunque cambie el slug de destino. |
WordPress Multisite añade otra capa de propiedad. Posts, Pages, términos, opciones y muchos registros de plugins son específicos de cada sitio, mientras que los usuarios pueden participar en toda la red. Los plugins activados a nivel de red y los servicios externos compartidos pueden introducir alcance adicional. Una exportación de origen que omita la identidad del sitio puede fusionar registros que estaban separados de forma intencionada.
El núcleo de WordPress y los plugins de comercio deben seguir siendo modelos separados
El núcleo de WordPress no ofrece Products, carrito, checkout, Customers, Orders, cupones, pagos, envíos, impuestos, inventario ni procesamiento de pedidos de forma nativa. Esas entidades pertenecen a WooCommerce u otro plugin de comercio. Pueden utilizar tipos de contenido, taxonomías, usuarios, metadatos, comentarios y tablas de WordPress, pero su significado empresarial procede de la aplicación de comercio.
| Concepto comercial | Relación con el núcleo de WordPress | Propietario real |
|---|---|---|
| Product y variación | Puede utilizar tipos de contenido personalizados, taxonomías, metadatos o tablas dedicadas | Plugin de comercio y sus extensiones |
| Customer | Puede conectarse con un usuario de WordPress o permanecer como identidad de una transacción como invitado | Plugin de comercio, CRM, sistema de membresía o plataforma de cuentas externa |
| Order y línea de Order | Puede utilizar tipos de contenido personalizados o tablas de comercio dedicadas | Plugin de comercio y extensiones de pago o procesamiento de pedidos |
| Reseña de Product | Puede utilizar comentarios más metadatos de valoración | Modelo de reseñas de Products del plugin de comercio |
| Registro de suscripción, reserva, paquete o vendedor | Puede hacer referencia a Products, usuarios y Orders | Extensión especializada o aplicación de marketplace |
| Contexto de pago, impuestos, envío y procesamiento de pedidos | Puede aparecer en registros históricos de transacciones | Integraciones comerciales y operativas, no contenido del núcleo de WordPress |
Una migración de WordPress y una migración de WooCommerce son, por tanto, alcances distintos aunque ambas utilicen la misma instalación. El destino debe identificar el plugin de comercio, su versión y modelo de almacenamiento, las extensiones instaladas y los sistemas externos antes de interpretar Products, Customers, Orders o registros específicos de la aplicación.
Un mapa de migración hacia WordPress debe conservar la propiedad y la capacidad de edición
El modelo de destino es coherente cuando cada registro tiene un tipo, propietario, sistema de clasificación, contrato de metadatos, ruta y superficie de edición definidos. El objetivo no es copiar el diseño de la base de datos de origen. Es conservar las relaciones que permiten a editores, administradores, aplicaciones y sistemas externos comprender los datos.
| Pregunta sobre el origen | Decisión de migración |
|---|---|
| ¿El registro es contenido editorial o una entidad de aplicación? | Elegir un tipo de contenido del núcleo, un tipo de contenido personalizado, un registro de plugin o un propietario en un sistema externo. |
| ¿Una agrupación clasifica registros o solo organiza la navegación? | Separar las relaciones de taxonomía de los menús y las páginas de destino. |
| ¿Un valor personalizado contiene datos o hace referencia a otro objeto? | Migrar tanto el valor como su relación con el objeto de destino. |
| ¿El diseño se almacena junto al contenido o en un sistema de constructor/plantillas? | Conservar el significado del contenido por separado de la implementación de presentación. |
| ¿Una cuenta es solo una identidad de inicio de sesión o forma parte de un sistema de membresía, aprendizaje, comercio o vendedores? | Mantener el usuario de WordPress y el perfil de la aplicación como registros distintos pero conectados. |
| ¿Una URL procede de un slug, una jerarquía, un archivo, un endpoint de plugin o el alcance Multisite? | Conservar la relación con el propietario de la ruta en lugar de depender de los títulos. |
| ¿La entidad pertenece al núcleo de WordPress, a un plugin, a una tabla personalizada o a una plataforma externa? | Mantener explícito el propietario real y conservar identificadores estables entre sistemas. |
Estas decisiones permiten que el sitio migrado siga siendo gestionable. Los editores pueden encontrar los registros correctos, las plantillas pueden representar los objetos previstos, los archivos y filtros pueden consultar las clasificaciones adecuadas, las cuentas conservan su significado dentro de cada aplicación y las integraciones continúan identificando las mismas entidades empresariales.
Conclusión
WordPress cambia el significado de los datos porque utiliza tablas centrales reutilizables para muchos tipos de registro y, al mismo tiempo, permite que plugins y código personalizado definan aplicaciones especializadas. Posts, CMS Pages, tipos de contenido personalizados, taxonomías, metadatos, archivos adjuntos, usuarios, comentarios, opciones, tablas de plugins, rutas y entidades comerciales pueden compartir infraestructura sin compartir significado empresarial.
Una migración coherente conserva esa propiedad. El contenido permanece conectado al tipo de contenido y la taxonomía correctos; los metadatos, a su contrato de campos y los registros referenciados; los medios, al contenido que los utiliza; los usuarios, a sus roles y perfiles de aplicación; las rutas, a los objetos que las poseen; y los registros de plugins o comercio permanecen separados del contenido ordinario del núcleo de WordPress.
Preguntas frecuentes
¿Los tipos de contenido personalizados de WordPress son lo mismo que las CMS Pages?
No. Ambos pueden almacenarse mediante el sistema de posts de WordPress, pero un tipo de contenido personalizado puede tener sus propias funciones del editor, taxonomías, capacidades, metadatos, archivo, comportamiento REST y plantillas. El destino debe conservar el tipo que representa la finalidad empresarial del registro.
¿Todas las Categories de origen pueden convertirse en una Category de WordPress?
No. La agrupación de origen puede corresponder a una Category estándar, una etiqueta, una taxonomía personalizada, una taxonomía de comercio, un menú de navegación, un campo de metadatos, un filtro de plugin o una clasificación externa. La elección depende de qué clasifica la agrupación y de cómo necesita consultarla o mostrarla el destino.
¿Por qué los campos personalizados de WordPress dependen tanto de sus relaciones?
Un campo personalizado puede contener un valor literal, el ID de otro registro, una referencia a un archivo adjunto, un término, un usuario, una estructura serializada o un estado de plugin. Copiar el valor visible sin migrar la relación o la definición del campo puede dejar inutilizables los datos de destino.
¿Los temas y los constructores de páginas son propietarios de los registros empresariales subyacentes?
Por lo general, no. Son propietarios de estructuras de presentación, plantillas, estilos y referencias de diseño. La CMS Page, Blog Post, Product, evento, listado u otra entidad sigue perteneciendo al núcleo de WordPress o al plugin correspondiente aunque un constructor controle cómo se muestra.
¿Deben tratarse los Products de WooCommerce como posts ordinarios de WordPress?
No. WooCommerce puede utilizar la infraestructura de WordPress, pero Products, variaciones, Customers, Orders, cupones, inventario, pagos, envíos, impuestos y extensiones pertenecen al modelo comercial de WooCommerce. Sus relaciones requieren una interpretación específica del comercio.
¿Cuándo deben los datos de WordPress pertenecer a una tabla personalizada o a un sistema externo en lugar de a un tipo de contenido?
El propietario viene determinado por la aplicación que gestiona el registro. Las transacciones de gran volumen, historiales especializados, relaciones complejas de muchos a muchos, registros de integración o flujos de trabajo específicos del dominio pueden residir en tablas de plugins o plataformas externas. El modelo de migración debe conservar la entidad y sus referencias sin forzarla a convertirse en un post genérico únicamente porque WordPress sea la infraestructura base del sitio.