The Data Migration Process That Supported Pet Media Group’s Future Strategy and Contributed to a 400% Revenue Increase

Right Mind was selected to build a single digital platform to serve as a unified system for all current and future marketplaces under the Pet Media Group umbrella. One of the biggest challenges we faced was designing a data migration process capable of moving millions of records without compromising data integrity or causing downtime in any marketplace. Discover the solutions we tested, what failed, and why we ultimately chose to use an ETL-based method.

About Pet Media Group

Pet Media Group (PMG) began as a friendly initiative to provide shelter for stray animals. Over time, it evolved into a network of online marketplaces for pet lovers worldwide. After several successful funding rounds and the acquisition of platforms such as Pets4Homes, Annunci Animali, and PuppyPlaats, PMG became one of the largest pet marketplaces in Europe. With more acquisitions on the horizon, technical challenges started to emerge — managing each platform separately was highly inefficient.

Business Background

PMG approached Right Mind because they needed a technical partner to bring their business vision to life. The goal was to build an integrated system of websites and apps that would unite all the acquired brands — and any future ones — on a single platform. The business idea was solid, but implementation was another story.

The main problem was that some platforms were outdated and each was built on different technologies. It was nearly impossible — or extremely expensive — to manage them all at once. PMG would have needed to hire developers with various skills and tech stacks. So, Right Mind was tasked with building a unified platform that would:

• Provide a way to migrate data
• Unify features across platforms
• Customize each platform based on local needs (language, laws, etc.)
• Address scalability
• Ensure the platform could accommodate future expansions
• In this article, we’ll focus on one of the most critical components of the project — the data migration process.

The Main Challenge – Migrating Data Without Downtime

The client wanted us to migrate data without taking any site offline. This was a serious challenge for ensuring data consistency. Why?

Imagine a user posts an ad to sell puppies at the same time we are migrating data to the new system. If they edit the ad shortly after posting it, but the migration already captured the first version, then the edit might never make it into the new system.

Now imagine this happening with millions of users and records — it was a huge risk to data accuracy, and one we couldn’t afford to take.

Data Migration Steps

Data migration is a multi-step process. For PMG’s case, we followed these stages:

1. Analyze Data Structures: Identify differences between old and new systems and locate any data gaps.
2. Fill the Gaps: Determine where to get missing data.
3. Prototype the Migration Tool: Run a small-scale test to estimate migration time.
4. Analyze the Results: Decide if a short system freeze is necessary.
5. Dry Run Migration: Run a non-live test to check data transfer accuracy.
6. Run the Actual Migration on the production environment.

Tiny moments, big calm.

The Technical Problem

Each marketplace was different in both features and data structure. The best solution was to unify the codebase and data schema.

But the main challenge remained: how do we move all that legacy data into the new platform, especially when some platforms had hundreds of thousands of records?

First Plan (That Failed)

We first thought of this plan:

1. Create a backup of the old database on a separate server.
2. Migrate from this backup.
3. Before launching the new platform, perform a diff (difference comparison) to transfer only the records that changed.

But this failed because:

• It’s difficult to define a precise cut-off point.
• Without clear IDs or timestamps for creation/updates, we couldn’t tell what changed.
• Any mistake would require restarting from scratch — impractical and risky.

Final Solution – ETL

We concluded that the only viable solution was to use ETL (Extract – Transform – Load):

1. Extract the data from the old system.
2. Transform the data into a format suitable for the new system.
3. Load it into the new platform.

But ETL came with its own challenges.

Challenge 1 – New Data Entering During Migration

We had two options:

• Use tools like AWS DMS to synchronize data in real time.
• Or use Maintenance Mode (MT mode) temporarily during migration.

We chose MT because some of the data required additional API requests during transformation, making real-time sync unreliable.

Challenge 2 – Incomplete Data

This highlighted how essential early data analysis is. If we had done deeper structural comparisons earlier, we would’ve avoided many issues. It’s critical to analyze both schemas and determine how each field should be transformed.

Challenge 3 – Need for Re-Runs

We had to ensure the migration process was:

• Idempotent – running it multiple times wouldn’t duplicate data.
• Resumable – if it failed at any point, we could restart from where it left off.

How We Built ETL for PMG

In the “standard” migration mode, this is how the flow worked:

1. Load data from the old marketplace’s database.
2. Transform it to match PMG’s structure.
3. Save the transformed data in a staging database.
4. Send it to PMG’s server.
5. PMG server validates it.
6. If valid: it saves the data.
7. If not: it logs the failure for future retry.

Additional Migration Modes

We created several other modes to accommodate various needs:

• Diff – migrate only changed records.
• LocalDiff – migrate only local changes.
• RetryFailed – retry failed migrations.
• FindMissing – migrate only missing data.

Benefits Achieved

Thanks to this robust migration solution, PMG was able to:

1. Unify its technical architecture.
2. Reduce operational costs.
3. Scale rapidly for future acquisitions.
4. Improve maintainability and update efficiency.
5. Contribute to a 400% increase in revenue.