In many Magento stores, the blog has been running for years, but its current technology is becoming less convenient to maintain. Over time, there is a need to simplify the architecture, make better use of native Magento mechanisms, and organize content without manually rewriting hundreds of posts.
In many Magento stores, the blog has been running for years, but its current technology is becoming less convenient to maintain. Over time, there is a need to simplify the architecture, make better use of native Magento mechanisms, and organize content without manually rewriting hundreds of posts.
Kowal_Blog solves this problem with a migration mechanism from existing blog modules to a new model based on the Magento catalog.
This means that changing the blog does not have to mean losing your existing editorial work or risking a sudden drop in search visibility.
What migration gives you
The most important value for the customer is simple: content that already exists can be moved to the new solution without building everything from scratch.
Migration makes it possible to preserve and organize:
blog posts,
categories,
tags,
basic SEO data,
the publication structure,
relationships between content and categories,
the URL history needed for redirects.
In practice, this means a shorter implementation time, lower editorial risk, and a lower cost of moving to a new solution.
Support for well-known Magento blogs
The migration mechanism was designed for real Magento implementations, where several well-known blog extensions are most commonly encountered.
Currently, migrations are supported from:
Amasty Blog,
Magefan Blog.
This is important because these are the solutions most often found in stores that developed the blog independently of the Magento catalog and now want to move it to a more consistent model.
Migration commands
Migration is launched from the Magento console:
bin/magento kowal:blog:migrate
The parameter specifies the module from which data should be retrieved. Available values:
amasty - import from Amasty Blog Pro,
magefan - import from Magefan Blog.
Basic migration from Amasty:
bin/magento kowal:blog:migrate amasty
Basic migration from Magefan:
bin/magento kowal:blog:migrate magefan
In the basic variant, the command uses the blog root category set in the configuration:
Stores > Configuration > Kowal > Blog > Blog Root Categories
If the configuration is not set or if a different blog root needs to be forced for a specific run, use the --root-category-id option.
The value 123 should be replaced with the Magento category ID under which the migrated blog categories should be created. This category becomes the target blog homepage and the root for the imported category tree.
Legacy URL prefix
The command includes the --legacy-prefix option, which specifies the old blog URL prefix used when creating 301 redirects.
The migrator transfers basic SEO meta data wherever it can be directly mapped to native Magento fields.
The most important rule: after migration, a blog post is a product of type blog_post, so post meta data is saved to the standard Magento product SEO fields. Blog categories are catalog categories, so their meta data is saved to the standard Magento category SEO fields.
Blog post meta data
For posts, the following are migrated:
meta title,
meta description,
meta keywords.
In the target blog_post, the fields are saved as:
meta_titlemeta_descriptionmeta_keyword
Thanks to this, after migration the post uses native Magento SEO mechanisms for products: page title generation, meta description, meta keywords, URL rewrite, and store view handling.
For Amasty Blog Pro, the mapping looks like this:
meta_title goes to meta_title,
meta_description goes to meta_description,
meta_tags goes to meta_keyword.
For Magefan Blog, the mapping looks like this:
meta_title goes to meta_title,
meta_description goes to meta_description,
meta_keywords goes to meta_keyword.
If the source post has separate values per store view, the migrator saves them as product store-view values. This means that multilingual or multistore post meta data can be preserved without manually rewriting it after migration.
Blog category meta data
For categories, the following are migrated:
meta title,
meta description,
meta keywords.
In the target Magento category, the fields are saved as:
meta_titlemeta_descriptionmeta_keywords
For Amasty Blog Pro, the mapping looks like this:
meta_title goes to meta_title,
meta_description goes to meta_description,
meta_tags goes to meta_keywords.
For Magefan Blog, the mapping looks like this:
meta_title goes to meta_title,
meta_description goes to meta_description,
meta_keywords goes to meta_keywords.
Amasty categories may have per-store-view data, and in that case the migrator saves the relevant values at the specific store view level of the Magento category.
Tag meta data
Tags in Kowal_Blog are modeled as options of the blog_tags product attribute. For this reason, their migration works differently from the migration of posts and categories.
The migrator transfers the tag name to the blog_tags option label and uses the old URL key or tag slug to prepare 301 redirects. Data such as:
meta title,
meta description,
meta keywords,
meta robots,
tag description,
is read from the source and preserved in the migration mapping data, but is not automatically saved as active tag page content in kowal_blog_tag_content.
After migration, it is therefore worth separately reviewing the most important tag pages in the Blog > Tags panel and completing their description and meta data if the tags are intended to be landing pages for SEO traffic.
Meta robots and Open Graph
meta_robots fields are read from Amasty and Magefan into the migration source data, but the current target model does not automatically save them on posts or categories as an active frontend field.
Similarly, additional Open Graph fields from Amasty, for example:
open_graph_meta_title,
open_graph_meta_description,
open_graph_meta_type,
as well as OG fields from Magefan, for example:
og_title,
og_description,
og_img,
og_type,
are preserved in the migration data, but are not automatically published on the frontend by Kowal_Blog.
If the customer uses advanced meta robots or Open Graph in the current blog, this should be included in the post-migration audit. Possible variants include:
manual setting of the most important values in the target SEO module,
preparation of an additional adapter or migration extension,
use of an external SEO module that generates robots and Open Graph for products of type blog_post and blog categories.
Meta data review after migration
After migration, you should check a sample of the most important SEO URLs:
posts with the highest organic traffic,
blog categories generating visits from Google,
tags that had their own indexed pages,
posts with custom meta title and meta description,
per-store-view versions, if the store is multilingual.
Minimum review in the Magento admin panel:
Open the imported blog_post type post.
Check Search Engine Optimization.
Compare Meta Title, Meta Description, and Meta Keywords with the source data.
Open the imported blog category.
Check the category SEO section.
For important tags, go to Blog > Tags and complete the description and meta data if they should be visible on the frontend.
Migration without manually rewriting content
One of the biggest advantages is that there is no need to manually recreate the blog.
Instead of:
copying texts post by post,
recreating the category structure,
rewriting tags,
manually fixing dozens or hundreds of URLs,
you can carry out a controlled migration to Kowal_Blog.
For the customer team, this means less operational work, and for the project, greater predictability.
Protecting your existing SEO
When migrating a blog, one key question usually comes up: what will happen to the existing URLs?
This is very valid, because old posts often:
already have organic traffic,
are indexed in Google,
have external links,
are used in marketing materials,
are tied to campaigns or newsletters.
That is why the migration mechanism in Kowal_Blog includes creating redirects for known post and tag URL structures. This makes it possible to move to a new URL model without leaving users and search engine bots on broken pages.
Additionally, the system generates reports of completed redirects and a separate URL collision report, so the implementation team can immediately see which paths were handled automatically and which require a decision.
A better foundation for further store growth
Migration is not just a one-time transfer of data. It is also about organizing the foundation on which the store will continue to operate.
After migration, the blog moves to a model that uses native Magento mechanisms, such as:
catalog categories,
store views,
URL rewrites,
EAV attributes,
standard Magento SEO,
Magento admin forms.
This simplifies development in the long term and reduces the number of separate, custom layers to maintain.
Migration can be prepared on customer request
Not every store uses one of the most popular modules. Some implementations run on older extensions, custom solutions, or modified versions of modules available on the market.
That is why the migration mechanism was designed to be extensible.
This means that in addition to ready support for well-known Magento blogs, it is also possible to prepare migration:
from another commercial blog module,
from the customer's custom solution,
from a custom data structure created in a specific project,
from an extension version that was previously modified for a given store.
From a sales perspective, this is a very important advantage. The customer is not limited only to the list of ready integrations. If a custom blog is running in the store, a dedicated migration path can be prepared for its specific data and business process.
Who this capability is especially valuable for
Migrating the blog to Kowal_Blog will be especially valuable for:
stores with a large number of articles,
brands that regularly publish SEO content,
multilingual projects,
companies planning to rebuild the blog without losing existing traffic,
stores that want to simplify the Magento architecture and reduce the number of parallel content systems.
The sales argument, directly
The customer is not buying only a new blog module here.
They are buying the ability to move from the current solution to a model that is more consistent with Magento:
without manually rewriting content,
while preserving the value of existing content,
with control over redirects,
with a report of completed operations,
with the option to prepare a dedicated migration if the current blog works in a custom way.
This shortens the path from the decision to change to the actual launch of the new blog and significantly lowers the barrier to entry for stores that already have a publication history.
