Freestyle — Adobe Commerce (Magento) Upgrade & Migration
Freestyle specializes in Adobe Commerce (Magento) upgrades and migration solutions tailored to your business needs. We ensure a seamless transition to the latest platform with minimal disruption to your operations. Our solutions enhance website performance, security, scalability, and user experience, empowering your eCommerce business with a future-ready platform built for growth and success.
1. Project Overview
The Freestyle project focused on upgrading an existing Adobe Commerce (Magento) application from version 2.4.7-p9 to 2.4.8-p5. The main objective was to maintain existing e-commerce functionality while aligning the application with the target release’s requirements. The upgrade covered Magento core packages, Composer dependencies, custom modules, third-party extensions, database configuration, caching, and external integrations. A structured approach was followed to identify compatibility risks and prepare the application for reliable deployment and future maintenance.
2. Existing Platform Assessment
Before starting the upgrade, the existing Magento environment was reviewed to understand its architecture, customizations, dependencies, and integrations. The assessment included the Magento version, PHP environment, Composer packages, installed modules, theme modifications, and database configuration. Supporting services such as the search engine, cache backend, message queue, and web server were also evaluated.
The review helped identify potential compatibility issues and determine which application or infrastructure components required changes. Particular attention was given to dependencies that could affect the upgrade process, including custom module implementations, third-party extensions, database configuration, and supporting services.
3. System Requirements and Compatibility
Magento 2.4.8-p5 has different software requirements from Magento 2.4.7-p9, making compatibility assessment an important part of the upgrade. Adobe’s published system requirements were used to identify compatible versions of PHP, Composer, database engines, search services, message queues, caching services, and web server software.
The final configuration was evaluated according to the deployment type, whether Adobe Commerce Cloud or an on-premises environment. Infrastructure changes were considered separately from the Magento package upgrade to avoid introducing unnecessary changes or unsupported software combinations.
The following table summarizes selected dependencies documented for the source and target releases.
| Component | Magento 2.4.7-p9 | Magento 2.4.8-p5 |
|---|---|---|
| PHP | 8.2 / 8.3 | 8.3 / 8.4 |
| Composer | 2.9.3+ | 2.10 |
| OpenSearch | 2 | 3 |
| MySQL (on-premises) | 8.0 | 8.4 |
| MariaDB | 10.11 | 11.4 / 11.8 |
| RabbitMQ | 4.1 | 4.3 |
| Redis (Cloud configuration) | 7.2 | Not listed as a supported standalone dependency in the target release table |
| Valkey | 8 | 8.1 |
| nginx | 1.28 | 1.30 |
This table presents selected software dependencies and is not a complete compatibility matrix. The exact supported configuration depends on the deployment type and the applicable Adobe Commerce documentation. OpenSearch 2 compatibility is retained for the 2.4.8 release line according to Adobe’s release notes, while OpenSearch 3 is listed for 2.4.8-p5. The specific search version must be verified against the applicable deployment requirements.
Similarly, the Redis and Valkey entries should be interpreted according to Adobe’s documented service configuration. The absence of Redis from the target release’s dependency table does not, by itself, establish that every Redis-based managed service is unusable. The actual cache and session configuration must be checked before planning a migration.
Reference: Adobe Commerce System Requirements.
4. Upgrade and Migration Approach
The Magento upgrade was managed through Composer by updating the required package constraints and resolving dependencies for the target release. Before applying changes, the existing codebase, dependency configuration, and extension requirements were reviewed. Once the package update was prepared, the required Magento database schema and data updates were executed using the appropriate upgrade procedure.
The application was validated in a staging environment before production deployment to identify compatibility issues and reduce operational risks. Any infrastructure changes required for the target release were assessed separately and coordinated with the application upgrade.
Key Activities Included
- Reviewing Magento package requirements and Composer dependencies.
- Checking custom modules, themes, and third-party extensions.
- Validating database and environment configuration.
- Verifying search, cache, indexers, and scheduled jobs.
- Performing functional and regression testing.
- Reviewing deployment dependencies and recovery procedures.
5. Database Migration and Validation
The existing Magento database was assessed before the upgrade to identify compatibility requirements, potential migration risks, and data integrity concerns. The assessment covered the database engine version, schema structure, existing tables, custom module data, database configuration, and dependencies on Magento core functionality. The database environment was evaluated against the requirements of Magento 2.4.8-p5 to determine whether database engine changes or configuration adjustments were necessary.
Before introducing changes, a database backup was prepared to provide a recovery point in case unexpected issues occurred during the upgrade. The backup and restoration approach was reviewed to ensure that the database could be recovered if critical problems affected application functionality or data integrity. Where applicable, the database backup was considered alongside the application code, Composer configuration, and environment settings to maintain consistency during recovery.
After the Magento packages were updated, the required database schema and data changes were applied using the appropriate Magento upgrade procedure, including bin/magento setup:upgrade. This command applies the schema and data updates required by installed Magento modules. The resulting database structure and module-specific data changes were then checked for alignment with the upgraded application.
Existing database tables, indexes, constraints, relationships, and custom module structures were considered during validation to identify potential issues affecting application operations. Particular attention was given to database changes introduced by Magento core packages and installed extensions.
The database engine was checked against the target release requirements, including the supported MySQL or MariaDB configuration applicable to the deployment environment. A Magento application upgrade does not automatically upgrade the database server itself. Where a database engine upgrade was required, it was treated as a separate activity with its own compatibility assessment, backup strategy, testing procedure, and recovery plan.
This separation helped reduce the risk of combining application-level changes and database engine changes without sufficient validation.
5.1 Database Schema and Data Integrity Validation
Following the schema and data updates, the database was validated to confirm that existing business information remained accessible and consistent. The validation covered Magento core entities, custom module tables, database relationships, and records used by important storefront and administrative workflows.
Key Validation Activities Included
- Product data validation: Checked product records, attributes, categories, prices, inventory information, and related catalog data to ensure that products remained available and displayed correctly.
- Customer data validation: Reviewed customer records, account information, addresses, and related data to confirm that existing customer information remained accessible.
- Order data validation: Reviewed order records, order items, invoices, shipments, credit memos, and associated transactional information where applicable.
- Store configuration validation: Checked store views, website settings, configuration values, and relevant settings stored in the database.
- Custom module data validation: Reviewed custom tables, extension-specific records, and relationships to ensure that project-specific business functionality continued to work as expected.
- Schema validation: Confirmed that the required database schema updates had been applied and investigated errors reported during the Magento upgrade process.
- Data consistency checks: Compared relevant record counts and representative business records before and after the upgrade, where appropriate, to help identify missing, inconsistent, or unexpectedly modified data.
These checks helped assess whether the database remained consistent with the upgraded application and whether existing business records continued to support essential Magento functionality.
5.2 Database Connectivity and Application Validation
Database connectivity was checked after the upgrade to confirm that Magento could establish connections using the configured database credentials, host, port, and connection settings. Database access was also evaluated through essential storefront and administrative operations to identify connection errors, query failures, or application exceptions.
Application logs were reviewed for database-related errors, including failed schema updates, SQL exceptions, missing tables or columns, and issues involving custom modules or third-party extensions. Where problems were identified, the relevant configuration, dependency, or module implementation was investigated and corrected before proceeding with further validation.
The database validation process was integrated with functional and regression testing. Product browsing, customer login, cart operations, checkout, order placement, and administrative workflows were included in the validation scope to confirm that database-dependent functionality continued to operate correctly.
Background operations such as indexing and scheduled jobs were also considered where they depended on updated database structures or records. This helped assess whether the database continued to support both customer-facing operations and administrative processes.
5.3 Database Migration Risk Management and Recovery
Database migration risks were managed through pre-upgrade assessment, backup preparation, controlled execution of schema and data updates, and post-upgrade verification. Particular attention was given to custom database structures, third-party extension tables, and changes introduced by the target Magento release.
The recovery plan considered the relationship between the application code and database state. Since database schema changes and data transformations cannot always be safely reversed, restoring only the previous application code might not be sufficient to recover the original environment. Where restoration was necessary, the recovery procedure accounted for compatible application code, dependency versions, database backups, and relevant environment configuration.
Database backup integrity and restoration procedures were considered important parts of recovery planning. Where applicable, backup restoration testing was used to establish whether the backup could support recovery within the required operational constraints.
Database engine changes, where required, remained a separately assessed and validated activity rather than being assumed to be part of the Magento application upgrade itself. This distinction helped keep application upgrade activities separate from database infrastructure changes.
The database validation process helped establish whether the database configuration, schema, and existing business information remained compatible with the upgraded application. Conclusions about successful migration and data integrity were based on the verification activities actually performed during the project.
6. Redis and Valkey Compatibility
The existing caching configuration was reviewed to determine whether the environment used Redis, Valkey, or a deployment-managed caching service. The target cache backend was checked for compatibility with the Magento release and deployment architecture.
Adobe’s published system requirements list Valkey 8.1 for Magento 2.4.8-p5. The appropriate caching and session storage configuration was evaluated according to the applicable release requirements and deployment type.
A Redis-to-Valkey migration was considered only where the existing environment and target configuration required it. Such a migration was treated as a separate infrastructure activity rather than an automatic consequence of upgrading Magento. Where a cache update was necessary, connectivity, cache invalidation, storefront behavior, and session handling, where applicable, were validated.
7. Custom Code and Extension Compatibility
Custom Magento modules, themes, and third-party extensions were assessed for compatibility with Magento 2.4.8-p5. Installed modules, Composer dependency constraints, vendor documentation, supported release versions, and PHP requirements were reviewed to identify potential conflicts.
Extensions requiring updates were evaluated for compatible releases, while custom modules were checked for deprecated APIs, incompatible implementations, and dependencies on existing Magento behavior. Database interactions within custom modules were also considered to identify possible compatibility issues following schema or data updates.
Frontend templates, theme overrides, and JavaScript customizations were reviewed for rendering and behavioral issues. Functional testing helped verify that existing business logic continued to operate correctly after the upgrade.
8. Composer and Dependency Management
Composer was used to manage Magento core packages and their dependencies during the upgrade. The existing composer.json and composer.lock files were reviewed to understand package constraints and installed versions.
Target Magento package requirements were updated according to Adobe’s version-specific upgrade procedure, and dependency conflicts were investigated before installation. The resolved package configuration was checked to ensure that Magento core and required extensions were aligned with the target release.
Composer dependency resolution was reviewed to identify incompatible package constraints, unsupported extension versions, and conflicts involving PHP requirements. The final dependency configuration was validated in staging before being promoted to production.
This process helped maintain consistency between Magento core packages, custom modules, and third-party dependencies.
9. Search, Queue, and Scheduled Operations
Supporting services were reviewed to confirm compatibility with the target Magento environment. OpenSearch configuration, catalog indexing, and product search were validated, particularly where the environment required a transition from OpenSearch 2 to OpenSearch 3.
A search engine transition was treated as a separate compatibility and infrastructure activity requiring its own assessment, configuration updates, and testing. The need for this transition depended on the actual source environment and target deployment configuration.
RabbitMQ configuration and queue consumers were checked to verify asynchronous processing where applicable. Cron jobs, indexers, static content deployment, and web server configuration were also reviewed.
These checks helped ensure that background processing and essential storefront operations continued to function correctly. Where service configuration changes were necessary, they were evaluated alongside application dependencies and deployment requirements.
10. API and External Integration Validation
Existing APIs and third-party integrations were reviewed to verify compatibility with the upgraded Magento application. The assessment covered API authentication, request and response handling, integration configuration, and data exchange.
Payment, shipping, ERP, and CRM integrations were included where they existed in the project architecture. Relevant workflows were evaluated to identify communication errors, authentication issues, unexpected responses, and changes in application behavior.
Integration testing helped verify that the upgraded application continued to support the connections required for existing business operations. Any issues identified during validation were investigated before the application was considered ready for release.
11. Functional and Regression Testing
Functional and regression testing was performed to ensure the upgrade did not affect existing features. Customer login, product listings, product details, search, shopping cart, checkout, and order placement were tested.
Administrative functions, custom modules, database operations, and external integrations were also validated. Background tasks, such as indexing and scheduled jobs, were checked where applicable.
Issues identified during testing were investigated and resolved before production release. This process helped confirm that the upgraded application continued to support existing business workflows and was ready for deployment.
12. Deployment and Recovery Planning
Deployment preparation included reviewing the target code, dependency versions, environment configuration, and required database updates. Static content deployment, cache operations, indexing, and service checks were performed according to the deployment setup.
Application logs and critical storefront and administrative workflows were reviewed after deployment. Backup and recovery procedures were maintained to support restoration if critical issues occurred. Because database schema changes could not always be safely reversed, recovery planning accounted for both application code and database state.
The deployment process also considered the sequence of application updates, database schema changes, cache operations, and supporting service checks. This helped ensure that the upgraded application and its dependencies were aligned before normal business operations resumed.
Where issues were identified during post-deployment verification, the relevant application, database, or infrastructure components were investigated according to the established recovery plan. Recovery activities were considered in relation to the consistency of the application code, database state, and environment configuration.
13. Upgrade Results and Validation
The Freestyle application was upgraded from Magento 2.4.7-p9 to 2.4.8-p5, with the objective of preserving existing business functionality. Compatibility assessment and regression testing addressed risks involving Magento packages, PHP, Composer dependencies, custom code, extensions, database configuration, and supporting services.
The database validation scope covered schema updates, data accessibility, database connectivity, and the integrity of relevant product, customer, order, store configuration, and custom module records. The target database configuration was evaluated against the applicable release requirements, and any required database engine changes were considered separately from the Magento application upgrade.
The target environment was evaluated against the applicable release requirements, and the storefront, administration, and required integrations were included in the validation process. Search functionality, background processing, caching, scheduled operations, and database-dependent workflows were also considered as part of the overall validation approach.
The upgrade activities established a foundation for future maintenance and platform upgrades. Implementation results and measurable improvements were documented based on the verification performed.