Not Content Migration — Meaning Migration: How WordPress Data Becomes OS iXanagi Knowledge

WordPress's central table is wp_posts. The design is deliberately simple and general-purpose. It stores blog posts, static pages, custom post types, navigation menu items, media attachments, and revision history — all in a single flat table.

The critical fields:

• post_content: The actual content, stored as raw HTML text
• post_type: A string identifier — 'post', 'page', 'product', 'attachment', and custom types
• post_status: 'publish', 'draft', 'private', etc.
• Related table wp_postmeta: Extension data stored as key/value pairs

The structural problem is in post_content. A product description, a blog article, a company history page, and a customer testimonial all live in the same column with the same data type. WordPress has no native mechanism to distinguish what a piece of content means — only what type of post it is and what category it belongs to.

Custom fields managed by plugins like Advanced Custom Fields (ACF) are stored in wp_postmeta as generic key/value entries. A field called acf_price in a database tells an external system nothing about whether that price is a retail price, a wholesale price, or a promotional discount. The meaning is implicit — understood only by the humans who built the site and the code that renders it.

This is the fundamental limitation that Meaning Migration addresses.

This is the question that governs everything about migration from WordPress to OS iXanagi.

Content (WordPress): "Our platform reduces operational costs by 30% compared to legacy solutions. Contact our sales team to learn more."

This lives in wp_posts.post_content. It is a string. A search engine can index it. A human can read it. A language model can summarize it. But no system can understand what role it plays in the business without reading the entire surrounding context.

Meaning (OS iXanagi): The same sentence, after Meaning Migration, becomes a structured object:

• Meaning Object type: Draft (content body)
• semantic_tags: ["value_proposition", "competitive_differentiation"]
• Domain: Financial, Demand
• locale: en (with a paired ja variant sharing the same group_key)
• Relation: contextually_cites → Knowledge Object containing the competitive benchmark data
• Relation: contains → CTA Object for the sales contact action

An AI Agent retrieving this Meaning Object knows it is a value proposition in the Financial domain tied to a specific competitive claim. It can answer questions about competitive advantage by citing this object. It can generate new content that references this claim accurately. It can alert the team when the 30% figure in the Knowledge Object it cites is updated or disputed.

This is the difference. Content informs humans. Meaning informs systems.

The average business WordPress site runs 20 to 50 active plugins (industry standard). Focus Reactive's 2026 research identifies plugin replacement as the single largest migration challenge. But the deeper problem is not the plugins themselves — it is that all the meaning encoded in plugin behavior, custom field structures, and taxonomy configurations exists nowhere in the database in an explicit, machine-readable form. OS iXanagi migration is the opportunity to make that meaning explicit for the first time.

The following table shows how each WordPress data element is treated in the migration:

WordPress	OS iXanagi
wp_posts (flat content)	Meaning Objects (semantically tagged content)
wp_postmeta (custom fields)	Knowledge Objects (structured knowledge)
Categories and tags (taxonomy)	Relations + semantic_tags (semantic connections)
Templates and themes (presentation)	Section Types + Projections (display design)
Plugin functionality (feature additions)	Pledge Sets (controlled function execution)
Page URLs (path-based)	Routes + parent_of Relations (meaning-based)
Comments	Inquiry management in Support App

The most consequential transformation is the shift from taxonomy to Relations. WordPress categories and tags are classification containers — a post "belongs to" a category. OS iXanagi Relations carry explicit meaning about why two objects are connected. A contextually_cites relation says this article references this knowledge object for a specific reason. A parent_of relation defines explicit hierarchy without relying on URL path inference.

For article #11 in this series on Content Link Graph, this distinction matters enormously: internal links in OS iXanagi are stored as Relation rows in knowledge_contextual_links, not embedded in content HTML. This makes link health checking, graph visualization, and SEO analysis possible in ways that WordPress's embedded-link model cannot support.

Every piece of content that enters OS iXanagi — whether from WordPress export, document upload, interview transcript, or web crawl — passes through the same Source Pattern architecture. This is a constitutional design: the Knowledge App is the single entry point for all meaning import.

The technical flow for WordPress migration is:

WordPress XML Export (WXR file)
  ↓
knowledge_sources  (registered as a named Source with brand_key)
  ↓
knowledge_source_items  (each post/page becomes a Source Item with locale and group_ref)
  ↓
knowledge_extractions  (AI generates extraction candidates per item)
  ↓
Human Review: Accept / Reject
  ↓
knowledge_objects / website_meaning_objects  (confirmed Meaning Objects)

Each extraction candidate in knowledge_extractions contains:

• extraction_type: signal / knowledge / content / profile / adaptation — the intended meaning function
• group_key: The locale-independent identity of this semantic unit (EN and JA rows share the same group_key)
• locale: en / ja / other
• confidence: AI confidence score (0 to 1.0)
• signal_meta_json: Contains intent, knowledge_boundary, thesis_affinity, contradiction_refs

The group_key + locale pairing is central to OS iXanagi's internationalization model. When a WordPress post has both an English original and a Japanese translation (managed via WPML or manual duplication), the migration assigns the same group_key to both. OS iXanagi then treats them not as translations but as locale adaptations of the same meaning unit — a distinction that matters when AI Agents retrieve content for multilingual operations.

Knowledge Extraction output produces two categories:

• Knowledge Objects: Structured knowledge — rules, facts, value propositions, competitive claims, policy definitions. These form the Knowledge Ontology layer that AI Agents reference.
• Meaning Objects: Content units — article bodies, FAQ pairs, CTAs, product descriptions. These are rendered through Projections in the Website App.

AI extraction achieves high accuracy on content with clear structure. It is less reliable on content that requires business context to interpret correctly. The HITL review step exists precisely to close this gap.

After AI generates knowledge_extractions, a human reviewer examines each candidate and marks it as Accept or Reject. Accepted items are converted to Meaning Objects via knowledge.extraction.decide — a Pledge that performs an idempotent upsert using the extraction's group_key and locale, ensuring the same semantic unit is never duplicated.

Common patterns where human intervention changes the outcome:

Outdated claims: AI extracts "We have 20 years of industry experience" as a brand claim. Reviewer notes the number is now 25. Rejects and re-registers with the corrected text.

Conditional knowledge: AI extracts "Return policy is 30 days" as a fact. Reviewer knows return periods vary by product category and adds applicable_conditions to the Knowledge Object before accepting.

Structural reorganization: AI generates three separate extractions that the reviewer recognizes as parts of a single FAQ pair. All three are rejected and manually reconstituted as one FAQ Meaning Object with the correct question-answer structure.

The quality of AI Agent outputs after migration is directly proportional to the quality of the Knowledge Objects they reference. Time invested in HITL review during migration is time invested in the accuracy of every AI interaction afterward.

Once Meaning Objects and Knowledge Objects are confirmed, they become live inputs to OS iXanagi Workflows that power AI Agent operations.

Blog generation (wf_blog_generator): The AI Agent consults Knowledge Objects containing product specifications, competitive claims, and customer insights — all migrated from WordPress custom fields and post content — to generate Briefs for new articles. Because the source material is structured and verified, the Agent's output is grounded in confirmed organizational knowledge rather than hallucinated generalizations.

Content sync (wf_content_sync): Content updates flow through Meaning Objects to all connected applications automatically. What required manual WordPress post editing and plugin configuration becomes a Workflow execution.

Knowledge health check (wf_knowledge_health): Periodic automated review flags Knowledge Objects that have exceeded their validity window or conflict with newer data. In WordPress, outdated information persists silently. In OS iXanagi, the system actively surfaces what needs updating.

For a broader view of how these changes affect day-to-day operations across IT, marketing, and leadership teams, see article #9: "Life After WordPress — What Actually Changes."

This is consistently the top technical question from IT teams evaluating migration.

ACF custom fields are stored in wp_postmeta as generic key/value pairs. For example, a product page with fields acf_price, acf_material, and acf_delivery_days is processed as follows during Migration Pipeline Step 4 (Mapping):

Flat value fields (text, number, boolean): Mapped to structure_json fields within Meaning Objects, or extracted as individual Knowledge Object attributes where they represent facts or rules.

Repeater fields and flexible content: These require deliberate redesign rather than automatic conversion. The IT team defines how each repeater row maps to Section Types in OS iXanagi's Projection system. A WordPress flexible content field with three layout types might become three distinct Section Type definitions.

Relationship fields (ACF Relationship): Object-to-object connections are expressed using OS iXanagi's Relation Vocabulary. An ACF relationship connecting a case study to a product becomes a references or contains Relation between the corresponding Meaning Objects.

The key principle is: do not attempt a 1:1 mapping of ACF fields to OS iXanagi fields. ACF configurations are often accumulated organically over years and frequently contain redundancy, ambiguity, or structural decisions that made sense in the WordPress context but do not carry over cleanly. The migration is an opportunity to redesign this structure with explicit semantic meaning.

Q1: Can we migrate ACF data completely? Yes, all ACF data can be migrated, but not through automatic 1:1 field conversion. Flat text and number fields migrate straightforwardly into Meaning Object and Knowledge Object structures. Repeater fields and relationship fields require mapping design work by IT staff during Step 4. The design effort is proportional to the complexity of your ACF configuration.

Q2: What about WooCommerce? WooCommerce product descriptions and catalog content can be migrated as Meaning Objects now. Full ecommerce functionality (cart, checkout, order management) will be handled by the OS iXanagi Commerce App, which is currently the highest development priority. For sites where ecommerce is the primary function, a phased migration approach — content first, commerce functionality when Commerce App is available — is the recommended path.

Q3: How do content editors work after migration? Post-migration, content is edited through structured form-based editors in the relevant App Console — Marketing Console for brand content, Website Console for site-specific content. This is different from Gutenberg's visual block editor. The trade-off is that content editing is more structured and less freeform, but every edit is semantically meaningful and immediately available to AI Agents without additional processing.

Q4: Can we test the migration in a staging environment before going live? Yes. Steps 1 through 7 of the Migration Pipeline execute entirely in OS iXanagi staging without affecting the live WordPress site. The full migrated content set can be reviewed, audited, and adjusted before any production deployment occurs.

Q5: What if we need to roll back after going live? Before DNS cutover (Step 8), rollback is trivial — WordPress remains live throughout. After cutover, rolling back requires pointing DNS back to WordPress and manually reconciling any Meaning Object updates made since migration. For this reason, completing the Step 7 Audit thoroughly and achieving a quality score of 80 or above before cutover is strongly recommended.

The technical substance of migrating from WordPress is not moving data. It is the design of meaning structures that did not exist before — explicit semantic tags, relation vocabulary connections, locale pairings, domain classifications, and knowledge scope assignments.

The content you have built in WordPress has value. The Migration Pipeline's purpose is to make that value legible to systems: to AI Agents that will generate content, answer questions, and execute workflows; to the Knowledge Graph that connects organizational knowledge across products and teams; and to the Content Link Graph that makes internal site structure navigable and measurable.

See article #7 for the full Migration Pipeline timeline and step-by-step operational guide. For the operational and strategic picture of post-migration life, see article #9.

For technical migration planning — from ACF mapping design to Source Pattern configuration — contact CloudEffects. We support the full technical scope of OS iXanagi migration.

---

Sources:

• Focus Reactive, "WordPress Migration Challenges Report," 2026
• Industry standard: WordPress plugin count benchmarks for business sites, 2025
• OS iXanagi Documentation: Source Pattern & Knowledge Extraction
• OS iXanagi Documentation: Meaning Objects & i18n Contract
• OS iXanagi Documentation: HITL Review Process