Magento 1 to Adobe Commerce: Building a Pre-Migration Performance Baseline

The single most common gap in Magento 1 to Adobe Commerce migration plans is the absence of a serious pre-migration performance baseline. Teams agree the migration will produce better performance, ship the project, look at PageSpeed numbers afterward, and either congratulate themselves or wonder why the new store doesn’t feel faster. Without a baseline, none of that conversation is grounded. The migration becomes a leap of faith, and post-launch performance discussions become arguments about subjective impressions instead of conversations about data.

This piece walks through what a proper pre-migration performance baseline looks like for Adobe Commerce migrations. It is written for engineering teams, technical project managers, and the eCommerce leaders who need to defend a six-figure migration investment to a CFO who will want to see the numbers afterward. The pattern below is what Bemeir’s Magento 1 migration practice uses on every engagement, and it has saved more than one project from a post-launch confidence collapse.

Why the Baseline Has to Exist

Three audiences need the baseline. The engineering team needs it to detect regressions during the build, every new module, every theme decision, every infrastructure change happens against the baseline, and unexpected slowdowns are caught early. The leadership team needs it to validate the business case, the migration was sold on specific performance and conversion improvements, and the post-launch comparison needs a starting point. The vendors and the agency need it to manage scope, if a particular page type was 4.5 seconds before migration and is 2.1 seconds after, that’s a defensible win even if other dimensions did not improve as much.

Without the baseline, none of these audiences can have grounded conversations. With it, every post-launch discussion is anchored in data.

The Three Layers of Measurement

A proper baseline covers three layers, each measuring a different aspect of performance.

The first layer is field data: Core Web Vitals from real users in production. This is what Google’s search algorithm uses, what actually affects conversion, and what your customers experience. Chrome User Experience Report (CrUX) data is the authoritative source, and you can pull it from the CrUX dashboard or directly through the BigQuery export.

The second layer is synthetic data: lab measurements from controlled tests. Tools like WebPageTest, Lighthouse, and SpeedCurve produce reproducible measurements that isolate specific variables. Synthetic data is less representative than field data but more controllable, which makes it useful for tracking regressions during the migration build.

The third layer is server-side measurement: time-to-first-byte, database query counts, query times, cache hit rates, memory usage. This data lives in your APM tool (New Relic, Datadog, AppDynamics) and tells you where backend time is going. The migration will change the backend characteristics, and you need to know the starting point.

What to Measure on the Field Side

Core Web Vitals measurement at the baseline should be segmented by:

• Page type: homepage, PLP, PDP, cart, checkout, account, search results
• Device: mobile vs desktop
• Geography: at minimum, US/EU split for stores serving both
• Returning vs new visitors
• Day of week and time of day, to surface load-correlated patterns

The metrics to capture are LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift). For each, capture the 75th percentile, which is what CrUX reports. Capture for at least 28 days before migration to establish a stable trend, with the comparison window being the same 28-day shape after migration. This controls for seasonality and other natural variation.

If your store doesn’t have CrUX coverage (it requires enough traffic), instrument the web-vitals JavaScript library on your existing Magento 1 store and pipe the data into your analytics tool. The library is small, runs in the browser, and captures the same metrics Google uses.

What to Measure on the Synthetic Side

Synthetic measurements should run on a fixed schedule against fixed URLs. The starting point is one synthetic test per page type, run every six hours from the same geographic location with the same simulated device profile. The output is a time series for each page type that the team can review during the build.

WebPageTest is the most thorough tool for this. Configure tests with consistent device profiles (a mid-range Android with a 4G connection is a good default for mobile), consistent test locations (Virginia for US, Frankfurt for EU), and consistent test scripts (login flows, add-to-cart flows). Capture filmstrip, waterfall, and full HAR exports for each test.

The synthetic baseline should include at least these scenarios:

• Cold cache homepage load
• Warm cache homepage load
• Cold cache PLP load (highest-traffic category)
• Cold cache PDP load (highest-traffic product)
• Add-to-cart flow
• Checkout step transition
• Logged-in customer dashboard load
• Returning customer cart resume

Each scenario produces a baseline measurement that becomes the comparison point post-migration.

What to Measure on the Server Side

Server-side measurements are the deepest layer and the one where the migration changes most. Capture these metrics from your Magento 1 production environment for at least 28 days:

• Median and 95th-percentile time-to-first-byte by page type
• Database query count per page type (Magento 1 stores often run hundreds of queries per page)
• Database query time per page type
• Memory usage per request
• Cache hit rates (Varnish, Redis, application cache)
• Cron job execution times and failure rates
• Backend admin response times
• API endpoint response times

This data comes from your APM. Both New Relic’s APM documentation and Datadog’s APM documentation cover the instrumentation patterns. If you don’t have an APM running, the baseline is the time to install one. The migration will benefit dramatically from having APM coverage on both sides.

The Conversion Baseline

Performance is interesting because it drives business outcomes. Capture the conversion rate baseline alongside the performance baseline so that the post-launch comparison can include both. Conversion rate by page type, average order value, cart abandonment rate at each step, and the funnel from PLP to PDP to cart to checkout, all of these are baseline metrics worth capturing.

Industry research consistently shows that performance improvements drive conversion improvements, but the size of the effect varies by category and customer behavior. Deloitte’s “Milliseconds Make Millions” report quantified the impact of mobile speed on retail conversion, and Akamai’s annual State of Online Retail Performance reports update similar measurements. Use the baseline to validate the specific effect on your store rather than relying on industry averages.

Documenting the Baseline

The baseline should live as a written document, a snapshot of the existing store’s performance at a specific point in time. Include:

• Date range of the measurement window
• Magento version, theme, extensions list, infrastructure profile
• Field data by page type, device, geography
• Synthetic measurements by scenario
• Server-side measurements
• Conversion baselines by page type
• Known issues and their planned fix in the migration

This document becomes the reference point for the entire project. Engineering uses it during development, leadership uses it during status updates, and the agency uses it to scope the work. Bemeir’s Magento 1 migration engagements treat this document as a deliverable in the first month, and the discipline pays back through the rest of the project.

What Changes Post-Launch

After cutover, the same measurements are taken again, in the same way, for the same window. The comparison is direct: same metric, same segmentation, same methodology. The new store either improved on the baseline or did not, and either way the team has data to act on.

A well-executed Magento 1 to Adobe Commerce migration with Hyvä typically produces:

• LCP improvements of 40-60% on PLP and PDP
• INP improvements of 30-50%
• CLS improvements that depend heavily on the design quality of the new theme
• TTFB improvements that depend on infrastructure choices
• Conversion rate improvements that lag performance improvements by 4-8 weeks

The specific numbers will vary by store. The baseline lets you know which numbers actually changed.

Beyond the Migration

The baseline discipline also lasts beyond the migration. The same measurement infrastructure that supports the migration becomes the ongoing performance monitoring stack for the new store. The same APM, the same synthetic tests, the same conversion segmentation. Once the discipline is in place, every future change, every new extension, every theme update, every infrastructure tuning, can be evaluated against the same baseline.

This is what separates serious eCommerce engineering from project-based work. The teams that build measurement discipline during a migration carry it forward and use it to drive continuous improvement. The teams that treat measurement as a migration deliverable lose the capability the moment the migration project closes. Bemeir’s Adobe Commerce engagements carry performance measurement into the retainer phase explicitly, because the value of the baseline compounds when it lives beyond the launch. The same compounding applies on the Hyvä migration practice, where ongoing performance work is the natural extension of the migration project.