MODX Evolution to Revolution Migration: Content, Templates, API

Our company is engaged in the development, support and maintenance of sites of any complexity. From simple one-page sites to large-scale cluster systems built on micro services. Experience of developers is confirmed by certificates from vendors.

Development and maintenance of all types of websites:

Informational websites or web applications
Business card websites, landing pages, corporate websites, online catalogs, quizzes, promo websites, blogs, news resources, informational portals, forums, aggregators
E-commerce websites or web applications
Online stores, B2B portals, marketplaces, online exchanges, cashback websites, exchanges, dropshipping platforms, product parsers
Business process management web applications
CRM systems, ERP systems, corporate portals, production management systems, information parsers
Electronic service websites or web applications
Classified ads platforms, online schools, online cinemas, website builders, portals for electronic services, video hosting platforms, thematic portals

These are just some of the technical types of websites we work with, and each of them can have its own specific features and functionality, as well as be customized to meet the specific needs and goals of the client.

Our competencies:

Development stages

Latest works

  • image_website-b2b-advance_0.webp
    B2B ADVANCE company website development
    1358
  • image_web-applications_feedme_466_0.webp
    Development of a web application for FEEDME
    1250
  • image_websites_belfingroup_462_0.webp
    Website development for BELFINGROUP
    956
  • image_ecommerce_furnoro_435_0.webp
    Development of an online store for the company FURNORO
    1188
  • image_crm_enviok_479_0.webp
    Development of a web application for Enviok
    929
  • image_bitrix-bitrix-24-1c_fixper_448_0.webp
    Website development for FIXPER company
    947

We often encounter site owners on MODX Evolution complaining about outdated architecture: PHP 5.6, no PSR compatibility, unpatched vulnerabilities. Evolution uses a procedural approach, global $modx objects, while Revolution is modern OOP with xPDO ORM. A direct upgrade is impossible — a full migration with code rework is required. Our MODX Evolution migration service transfers all content, templates, and custom code, ensuring a smooth transition and SEO preservation. Evolution does not support modern caching and autoloading standards, leading to slow performance and scalability issues. Revolution provides built-in caching, PSR-compatible classes, and a flexible event system. For example, in Evolution, to output a list of documents you had to write direct SQL queries, increasing the risk of SQL injection. In Revolution, this is handled via xPDO with automatic escaping.

Key Benefits of MODX Evolution Migration

Switching to Revolution delivers measurable benefits: average page load time is halved thanks to built-in caching, old architecture vulnerabilities are eliminated, and access to modern packages and autoloading is gained. Hosting cost savings can reach 30% — for a typical site with 50 resources, that means saving $500–$2000 annually on hosting. Additionally, Revolution supports PHP 8.x, extending the site's lifecycle. Support and development costs are reduced by up to 40%.

What is Migrated in MODX Evolution Migration

Component Method
Resources (pages) Export to JSON, import via Revolution API
TV parameters Keep name mapping
Templates Rewritten as Revolution chunks
Snippets Refactored for new API
Plugins Rewritten using Revolution events
Images Rsync from assets/
Users Import via API

The folder structure for images is usually identical, but paths in content may change. We automate replacement via regex or manual mapping.

MODX Evolution Migration Process

The migration follows these steps:

  1. Audit – we analyze the current site structure.
  2. Export – we export all data to JSON.
  3. Import – we import into Revolution.
  4. Refactor – we rewrite snippets and plugins.
  5. Test – we thoroughly test the new site.

Step 1: Analysis of the Current Site

Before migration, we conduct an audit: collect data on templates, TV parameters, snippets, and plugins. Example SQL query to estimate workload:

-- Count documents by template
SELECT t.templatename, COUNT(d.id) as count
FROM site_content d
JOIN site_templates t ON t.id = d.template
GROUP BY t.templatename;

-- TV parameters
SELECT tv.caption, tv.type, COUNT(tvv.id) as used
FROM site_tmplvars tv
LEFT JOIN site_tmplvar_contentvalues tvv ON tv.id = tvv.tmplvarid
GROUP BY tv.id;

-- Custom snippets
SELECT name, LENGTH(snippet) as size FROM site_snippets;

-- Plugins
SELECT name, plugincode FROM site_plugins WHERE disabled = 0;

Step 2: TV Parameters Migration

TV parameters are mapped by name. If in Evolution the field was called color, it remains color in Revolution. It is important to check types: in Evolution, the TV type may differ from Revolution (e.g., text field vs. text area). We adjust types manually. Additionally, we configure access to TVs via Revolution system settings.

Step 3: Snippets and Plugins Migration

Evolution snippets are written in procedural style with global $modx. The Revolution API is different. For example:

// Evolution (old API)
$docs = $modx->getDocuments($parents = [5], $published = 1);

// Revolution (correct API)
$c = $modx->newQuery('modResource');
$c->where(['parent' => 5, 'published' => 1]);
$docs = $modx->getCollection('modResource', $c);

Snippets need to be rewritten. For typical tasks (listing, menus, forms), use ready-made Revolution extras: pdoResources, pdoMenu, FormIt. This speeds up development and reduces error probability.

Step 4: Images and Files Migration

# Image structure is identical (assets/images/)
rsync -avz old-server:/var/www/evo-site/assets/images/ \
    /var/www/revo-site/assets/images/

Detailed Migration Checklist

  1. Inventory all Evolution components (templates, snippets, plugins, TVs).
  2. Export database and assets to JSON and folders.
  3. Install Revolution with required packages.
  4. Map old TV names to new Revolution TVs.
  5. Rewrite each snippet to use xPDO queries.
  6. Convert plugins to Revolution events.
  7. Import content via Revolution API with proper resource IDs.
  8. Adjust all internal links and image paths.
  9. Set up 301 redirects for changed URLs.
  10. Test all functionality on staging environment.
  11. Perform load testing to verify performance gains.
  12. Deploy to production and monitor.

Real Case: E-commerce Store in 4 Weeks

Our client had an e-commerce store on Evolution with 300 resources, 20 snippets, and 10 TVs. We completed the MODX Evolution migration in 4 weeks. Key issues:

  • The cart snippet used direct SQL queries — rewritten to xPDO.
  • Templates contained outdated [+...+]] tags — replaced with Revolution [[+...]].
  • URL structure changed, .htaccess redirects configured.

The client noted: "Loading speed increased by 40%, and server load dropped by half."

Result: page load speed increased by 40% thanks to Revolution caching, vulnerabilities eliminated, server load reduced. Hosting savings up to 30% (about $500/year). Want the same? Order a free audit of your Evolution site.

Performance Comparison: Evolution vs Revolution

Revolution loads pages 2 times faster than Evolution, confirming its superior performance.

Parameter Evolution Revolution
Average page load time 1.2 sec 0.6 sec
Memory usage 32 MB 48 MB
Caching None Built-in (SQL, file)

Revolution is 2x faster in load time, and caching reduces server load.

Timeline and Cost

Site Type Timeline Starting Price
Simple site (up to 50 resources, standard snippets) 1–2 weeks $1,500
Medium (100–500 resources, custom snippets) 3–5 weeks $3,000
Large (1000+ resources, complex functionality) 2–3 months $10,000

Costs are project-based; final estimate after audit.

What's Included in the Work

  • Audit: analysis of templates, snippets, TVs, plugins.
  • Export: all data preserved as JSON.
  • Revolution setup: installation and caching configuration.
  • Migration: content import with template and snippet refactoring.
  • File transfer: image sync with automatic path fixes.
  • SEO preservation: 301 redirects for URL continuity.
  • Testing: staging environment verification.
  • Documentation: admin guide and training.
  • Post-release support: 30 days free bug fixes.

Why Trust Us

  • 10+ years of experience with both MODX versions.
  • Over 50 completed MODX Evolution migration projects.
  • Certified MODX Revolution engineers.
  • Quality guarantee: free bug fixes within 30 days.

Contact us for a free workload assessment. Order migration and forget about Evolution issues. Get a consultation within 2 business days.

Website Redesign and Migration: CMS Change, SEO Preservation

A client came to us 6 weeks after a self-attempted redesign: 'We moved from WordPress to Tilda, traffic dropped by 70%.' I opened Google Search Console — 847 pages returned 404, the URL structure had completely changed, not a single 301 redirect was in place. Yandex hadn't reindexed the new site yet, positions collapsed. Recovery took 4 months and resulted in significant revenue loss for the quarter. Our experience — over 7 years and 80+ successful migrations, we guarantee position retention with the right approach.

Why Do Migrations Break SEO?

Search engines have indexed specific URLs. If /catalog/shoes/nike-air-max-270 turned into /products/nike-air-max-270 without a 301 redirect — all the link equity, traffic, and rankings go nowhere. Google says 301 passes ~99% of PageRank, but in practice positions recover over 2–8 weeks, not instantly.

Commonly, SEO gets broken not out of malice, but because a developer doesn't view the URL structure as a public API. Here are typical breakages:

Problem Cause Solution
Duplicate content New site opened parallel to old Disable indexing of dev version, set canonical
Loss of metadata Title and description left in old CMS Export via API, mass import with verification
Canonical changes Pagination and filters reset Lock before development, implement in template
Speed drop Heavy sections, unoptimized images Optimize LCP, CLS, TTFB before launch

How to Recover Traffic After a Failed Migration?

If traffic dropped, act immediately:

  1. Crawl the new site for 404s and compare with the pre-migration URL list.
  2. Create redirects for all lost pages with traffic >0.
  3. Check structured data and meta tags on a test sample.
  4. Daily monitor Coverage in Search Console and positions for top 50 queries.
  5. If after 2 weeks traffic does not recover — deep audit of redirects (transitivity, chains, loops).

In our practice, a large e-commerce site lost 50% of traffic when moving from Bitrix to React + Strapi. We restored 95% of redirects in three days, and within 3 weeks traffic returned to 90% of original.

What Does a Pre-Migration Audit Include?

Before starting development on the new site:

  1. Full crawl of current site via Screaming Frog or Sitebulb. Get list of all indexable URLs with traffic from Google Search Console.
  2. Export all pages with organic traffic >0 over the last 6 months — these are priority for redirects.
  3. Record all external backlinks to specific pages — Ahrefs, Semrush.
  4. Snapshot current positions for key queries — baseline for post-migration comparison.
  5. Save Core Web Vitals from Search Console for the previous 90 days.

Table for recording:

Audit Stage Tool Criticality
URL collection Screaming Frog + GSC High
Page traffic Google Analytics / Search Console High
External links Ahrefs / Majestic Medium
Positions Yandex Wordstat / Serpstat Medium
Core Web Vitals GSC CrUX High

Contact us for a detailed pre-migration audit — we will help identify all risks and create an action plan.

URL Mapping and Redirects

For projects with 200+ pages, we create a mapping table: old URL → new URL → status (301, merged with another page, deleted). Each row is verified: does the content actually migrate here?

In Laravel, redirects are handled via configuration file and middleware, not .htaccess — faster and more manageable. For WordPress → Next.js: redirects are set in next.config.js (static) and at the Nginx/CDN level for dynamic ones. Old .htaccess on shared hosting with 500+ lines of redirects is a special hell. Each redirect is checked sequentially, performance suffers. We move to Nginx map directive or Redis cache for dynamic lookup. More at Wikipedia: HTTP 301.

How to Migrate Content from Different CMSs?

WordPress → Headless CMS (Contentful, Strapi, Sanity): WordPress REST API or WP All Export to export posts, meta fields, media files. Migration script in Node.js: parse export, transform structure, upload via CMS API. Media files are reuploaded to new storage, links updated in content. Typical problem — shortcodes in WordPress content ([gallery id="123"]): need parser and transformation to new format.

1C-Bitrix → modern stack: Bitrix stores content in non-standard tables with IBLOCK_ELEMENT_PROPERTY. Direct SQL export via phpMyAdmin or Bitrix API. Transformation is the longest part due to specific Bitrix data structure.

Heavy WYSIWYG → structured content: Years of editing in FCKEditor/TinyMCE leave inline styles, non-standard tags, broken attributes. HTML sanitize + transformation to Markdown or Portable Text (Sanity) with manual check of problematic pages.

CMS Migration Tools Complexity Risks
WordPress WP All Export, WP-CLI, REST API Medium Shortcodes, meta fields
1C-Bitrix Bitrix API, SQL export High Complex structure, infoblock properties
Joomla J2XML, direct DB export High Outdated extensions
Tilda/Readymag API export (limited) Medium No full content access

How to Preserve Technical SEO Elements During Migration?

Structured data (Schema.org) — if the old site had Product, Article, BreadcrumbList markup, they must be on the new site too. Google Search Console → Enhancement reports will show loss of rich snippets.

Sitemap XML: generated automatically, submitted to GSC a day after launch. Old sitemap remains until full reindexing.

hreflang for multilingual sites: if tags are lost during migration, conflicts between language versions in search results will start within weeks.

Open Graph and Twitter Card meta tags — often forgotten when changing template, pages stop displaying correctly when shared on social networks.

Launch and First Weeks Monitoring

DNS propagation: DNS switching takes up to 48 hours, plan launch with buffer. Cloudflare as DNS provider — propagation takes minutes, not hours.

After launch, monitor daily: Search Console → Coverage (indexing errors), Analytics → organic traffic, year-over-year comparison, crawl site for 404 errors.

First 2 weeks are critical. If traffic drops more than 30% — immediate audit of redirects and comparison with pre-migration crawl.

Launch checklist (spoiler)
  • [ ] All 301 redirects work and do not form chains
  • [ ] Sitemap submitted to GSC and Yandex.Webmaster
  • [ ] Canonical tags set on all pages
  • [ ] Open Graph / Twitter Card display checked
  • [ ] robots.txt and noindex meta tags adjusted
  • [ ] Core Web Vitals in green zone (LCP <2.5s, CLS <0.1, INP <200ms)

What the Service Includes

Results you receive:

  1. Migration plan with URL mapping and redirects in Excel/Google Sheets format.
  2. Configured 301 redirects at server level (Nginx/Cloudflare/Vercel).
  3. Migrated content with integrity check: images, meta fields, links.
  4. Structured data (Schema.org) on the new site, identical to old or improved.
  5. SEO report: position trend at 1, 3, and 6 weeks after launch.
  6. Coverage monitoring in Search Console with error notifications.
  7. Guaranteed position retention: if traffic drops more than 15% within the first month — free audit and correction.

Timelines and Estimates

  • Redesign with migration for a small site (up to 100 pages): 4–8 weeks.
  • E-commerce migration with 500+ product pages: 8–16 weeks.
  • Only technical migration part (redirects, metadata) without redesign: 1–3 weeks.

Cost is calculated individually based on scope.

Get a consultation for your project — we will respond within a day. Order a pre-migration audit of your site and receive a detailed proposal with a redirect plan. Contact us to discuss details.