Recipe Migration in Practice: What Actually Happens During a Recipe Migration

You’re thinking about a recipe migration. Maybe your 200 recipes are stuck in WP Recipe Maker and you want out. Maybe Tasty Recipes changed its pricing model again and you’re wondering if this is sustainable. Or you’re planning a complete platform switch.

The question everyone has: What actually happens? How much work is it? And what can go wrong?

We migrate recipe blogs. It’s a core part of what we do. And because “we take care of everything” isn’t a satisfying answer, we’re laying the process open. Six phases, each with a concrete outcome.

Why Recipes Aren’t Normal Blog Posts

A travel article is a block of text with images. A recipe is a dataset.

Ingredients with quantities and units. Preparation steps in a fixed order. Times — prep, cooking, total. Serving sizes. Nutritional information. Difficulty level. Cuisine. Dietary category. And then: step photos, gallery images, a hero image for schema markup.

On top of that come the things people easily forget: comments that readers have left on recipes over the years — questions, tips, variations. And ratings — the stars that make your recipe look great in Google search results.

In most food blogs, all of this doesn’t live in standard WordPress tables but in proprietary plugin databases. wp_wprm_recipes, wp_wprm_ingredients, wp_wprm_ratings — tables that only exist because WP Recipe Maker created them. Deactivate the plugin, and the data becomes invisible. Not gone, but invisible.

A migration needs to extract, transform, and transfer all of this into a new format. This isn’t a copy-paste job. It’s a data project.

Phase 1: Decision and Goals

Before anyone exports anything, we clarify three questions.

Where should it go? Plugin switch within WordPress? From a plugin to native theme fields? Or completely off WordPress — to a static setup, Next.js, or another system?

What’s the inventory? Which plugin is currently in use? How many recipes exist? Which fields are actually populated — and which are empty? How many comments and ratings exist, and where exactly is the data stored?

What’s the goal? Should all recipes be migrated or only those with traffic? Should comments come along completely, or is a curated selection enough? Do all old URLs need to be preserved?

At the end of this phase, a migration plan is on the table. Scope, priorities, expected stumbling blocks — everything documented before a single line of code is written.

Phase 2: Content Download

Now it gets technical. We extract everything your blog contains in terms of recipe data.

Recipe data. Standard plugin exports are almost never enough. WP Recipe Maker exports a JSON, but without images, without comment associations, and without the recipe-to-post linking. So we write custom export scripts that access the database directly.

Ingredient parsing. “200g flour” sounds simple, but plugins store this differently. Some cleanly separate quantity, unit, and ingredient into three fields. Others pack everything into a single string. We parse it so that structured data comes out the other end — regardless of how the source plugin organizes data internally.

Images. Hero images, step photos, gallery images. We don’t just back up the files but also the associations: which image belongs to which step, which is the featured image, which is used for schema markup.

Comments. WordPress stores comments in wp_comments by default — they don’t belong to the plugin. But the association to the correct recipe and the thread structure (who replied to whom) must be preserved. In some setups, comments also live in plugin tables, for example when a recipe-specific comment field was used.

Ratings. The stars readers give your recipes almost never live in standard WordPress tables. WP Recipe Maker has wp_wprm_ratings, Tasty Recipes stores ratings in post meta fields, other plugins have their own solutions. We extract both individual ratings and aggregated averages.

Phase 3: Content Preparation

Raw data isn’t finished content. In this phase, we transform everything for the target system.

Field mapping. Every plugin has a different data model. WP Recipe Maker structures ingredients in groups with subgroups. Tasty Recipes does it differently. We map every source field to the target structure — whether that’s another plugin, native theme fields, or an entirely different system.

Ingredient normalization. “Tomatoes”, “tomato”, “fresh tomatoes”, “tomatoes (peeled)” — four entries that mean the same thing. For clean filtering and search on the new platform, you need consistent naming.

Image optimization. New formats (WebP), appropriate sizes for responsive display, filling in missing alt texts. Images often account for 80 percent of transfer volume — attention to detail pays off here.

Comment cleanup. Filter out spam, verify comment author associations, correctly transfer thread structure (replies to replies) into the target format. A comment thread with 30 posts where half is spam and the nesting is broken does more harm than good.

Rating aggregation. Transfer individual ratings and averages into the target format. Especially important: building the Schema.org AggregateRating correctly so Google continues showing stars in search results. 4.7 stars from 89 ratings — that needs to be exact after migration.

Schema.org markup. Prepare JSON-LD for every recipe — with all required fields (name, image, recipeIngredient, recipeInstructions) and rating data. The markup determines whether Google shows your recipe as a rich result or a plain link.

URL mapping. Map old URLs to new ones so we can set up clean 301 redirects in Phase 6.

Phase 4: Content Upload

The prepared data goes into the staging environment — a copy of the target platform that isn’t public yet.

Import. Each recipe gets attached to the correct post. The recipe-to-post linking must be accurate, otherwise the lasagna recipe suddenly appears under the banana bread article. Sounds trivial, but with 200+ recipes it isn’t.

Taxonomies. Cuisine, course, dietary category, difficulty level — all assignments are created in the new system and linked to the recipes.

Comment import. The cleaned-up comments are imported with correct thread structure and timestamps. Who replied to whose comment must still be visible after migration.

Rating assignment. Individual ratings are assigned to recipes, averages verified. The AggregateRating in the schema markup must match the actually imported ratings.

Visual spot check. Do the recipes look right? Are the images correct? Are the ingredients complete?

Phase 5: Content Test

The staging environment is up. Now we test.

Schema.org validation. Every recipe goes through the Rich Results Test. If a required field is missing, the recipe won’t appear as a rich result on Google — meaning stars, prep time, and image disappear from search results.

Rating verification. Do the averages match? If a recipe had 4.7 stars from 89 ratings before, it must be identical after migration. Google catches discrepancies between displayed stars and schema markup — and penalizes it.

Comment verification. Thread structure intact? Replies properly nested? No spam slipped through? On a food blog with an active community, comments are real content — readers ask about substitutions, share variations, offer tips. That can’t be lost.

Images and step photos. Correct associations, quality, load times. A recipe with swapped step photos is worse than one without any.

Staging access. You get access to the staging environment and check your recipes yourself. Nobody knows your content better than you — if your grandmother’s lasagna is missing two ingredients, you’ll notice before we do.

Phase 6: Go-Live and Babysitting

Everything checked, everything approved. Now we flip the switch.

DNS and redirects. The new platform goes live, all old URLs get 301-redirected to the new ones. This isn’t optional — without redirects you lose your Google rankings overnight.

Notify Google. Submit new sitemap in Search Console, request indexing. Google needs a few days to process the changes.

30-day monitoring. We watch rankings, rich snippets, traffic. Are the stars still showing? Are the new URLs being indexed? Are there 404 errors we missed?

Follow-up work. Individual recipes where an image is missing or an ingredient is incorrectly formatted. Comments that came in on the old platform after the cutoff date. Ratings that need to be backfilled. This phase is mandatory, not a nice-to-have.

What a Recipe Migration Is Not

Not “click export, click import, done.” That works for a WordPress blog post with text and images. For recipes with structured data, ratings, comments, and schema markup, it doesn’t.

But it’s also not a months-long mammoth project. The six phases are a proven workflow that we adapt for each food blog. Most of the work is in Phases 2 and 3 — export and preparation. The rest is methodical but plannable.

The honest truth: the cleaner the source plugin stored its data, the smoother the migration. A blog with 150 recipes in WP Recipe Maker where every field is properly filled out migrates much more easily than one with 300 recipes spread across three different plugins over eight years.

Planning a recipe migration? Let’s look at your starting point together. Or read the broader recipe migration guide first if you want to understand where the pitfalls are.

Learn more about our migration service: Migration.