How scandiweb Migrates from a Legacy eCommerce Platform to Magento

Staying ahead means constantly evaluating your eCommerce platform and adapting it if needed. For many online stores, this evolution necessitates migrating from older platforms to more modern, feature-rich solutions like Magento (Adobe Commerce). It’s always a big step, but it needs to be taken sooner rather than later. 

This article lists challenges in eCommerce migration projects, such as working with third-party models and custom code, limited documentation, and outdated endpoints. We also explore strategies to overcome these challenges, including reading source code and validating functionality. Gain insights into our approach to deliver successful Magento migrations!

Why eCommerce stores need migration?

eCommerce stores might find themselves at a crossroads for several reasons:

• Their current platform is no longer supported, leaving the store vulnerable to security risks, compatibility issues, and other challenges that affect daily operations and long-term growth
• Lack of technical support due to studios or developers who originally set up and maintained the platform are no longer available or have shut down
• Difficulties implementing new features, fixing bugs, or performing routine updates.

Migration from a legacy system

Migrating from a legacy system to a new platform like Magento entails more than transferring data; it requires a complete understanding of the intricacies of the old system, planning the migration to ensure minimal disruption to the business, and executing it with precision, ensuring that all critical data and custom features are seamlessly transitioned to the new platform. 

Usually, at the start of a migration project, discovery needs to be done, and by done, we mean it needs to be redone.

Original project discovery is done based on the knowledge in the project owner’s head and the high-low estimate based on that, with the understanding that it will increase as the Development team finds more things that need to be done. At this point, the team doesn’t know anything in-depth, and there’s a high chance of encountering crucial parts of the project that were not initially discovered or were discovered and not covered fully or covered incorrectly. 

Finding the business logic becomes the primary mission. It’s unknown what is crucial or not, so we need to find everything. 

The only way to guarantee smooth migration in these situations is to delve into the source code of the original platform. That doesn’t mean reading the entire code but looking for and tracking various hooks, observers, plugins, and alternatives for that eCommerce. It also means searching for controller modifications, cronjobs, and basically any entry points that can do things, finding out what it is and whether the new platform needs it. 

To reiterate, reading the source code, making an extensive list of uncertainties, reviewing it with a client, and identifying important things—it’s the most efficient way to set up a successful migration project and avoid fixing bugs later on. 

Our approach to migration projects

scandiweb’s approach to migration is based on the principles explained above. Before any migration, our developers delve into legacy source code to understand it fully. It can be Magento 1, OXID, Shopware, or anything else; PHP, C, Python, or another programming language, and sometimes we look at the code in middleware. Even blackboxes can be observed by their input/output. 

Building on our foundational approach to migration, the next steps focus on discovering and understanding the business logic. This stage is critical because often, there are functionalities and processes integral to the business that were not initially communicated to the Development team. These could be elements or functionalities that the project owner considered obsolete or unaware of their critical importance to the business’s operations post-migration.

We then do further discovery, evaluating each element to determine its relevance in the new ecosystem. We assess whether certain functionalities should be carried over as they are, modified for better efficiency, or replaced with more modern, scalable solutions. While essential at the moment, some features may not align with the business’s future growth plans or Magento’s capabilities—in such cases, our team proposes better alternatives. 

In-depth discovery and analysis ensure that no critical functionality is overlooked and that the migration sets a solid foundation for the business’s growth, helps avoid mid-migration surprises, and saves time and resources in the medium to long term.

Let’s look at two legacy platform to Magento case studies.

1) Example: custom Magento 1 to Magento 2

Project background

When approaching scandiweb, the client’s online store was built on Magento 1 and enriched with over five years of custom development. The platform was heavily customized with numerous third-party modules and bespoke code tailored to the client’s business needs. As Magento 1’s end-of-life neared, the urgency to migrate to Magento 2 became apparent. 

Complicating the situation was that the original developer who had crafted the custom solutions was no longer available, and the project lacked comprehensive documentation. The knowledge of the platform’s intricacies was limited to the project owner and a few close associates, presenting a significant challenge for migration.

Approach

Understanding the complexity and the customized nature of the client’s Magento 1 setup, our initial step was to conduct a thorough discovery process. This process was built on what the project owner and associates knew, which, while extensive, did not cover the full depth of the customizations and integrations. 

Recognizing the gaps in our understanding and the potential for overlooked functionalities crucial to the business’s operation, we thoroughly analyzed the Magento 1 source code.

This deep dive into the code allowed us to map out all the customizations, third-party modules, and unique code developed over the years. We identified core functionalities to understand how these customizations interact with Magento 1 and to ensure no vital feature was left behind during the migration.

Additionally, we discovered that several third-party modules used in Magento 1 would not be compatible with Magento 2, so we offered alternatives. 

With a comprehensive understanding of the custom Magento 1 setup, we devised a migration strategy that prioritized data integrity, feature consistency, and system improvements. 

Results

Through careful planning, in-depth code analysis, and close collaboration with the client, we successfully transitioned their highly customized Magento 1 store to Magento 2. We achieved improved performance and enhanced security on a platform ready for future growth and innovation. 

2) Example: OXID to Magento

Project background

Our client was ready to migrate their store from OXID to Magento—a complex undertaking due to the significant absence of documentation, particularly around ERP integration. The OXID platform, while lesser-known, was deeply outdated with extensive customizations, with the original developers no longer working on the project. They had an archaic ERP system and an old .NET middleware interacting with the ERP, both integral to the client’s operations but operating as blackboxes without being able to change much.

Despite these challenges, we got some minor documentation from the OXID environment, and they provided auto-generated API documentation via Swagger. This consisted of interface definitions, endpoint functionalities, and data schema expectations. However, the documentation was far from complete or reliable, with inaccuracies in required field indications, outdated and unused endpoints, and generally misleading information. 

Approach

Here’s a step-by-step of what this product migration entailed:

1. Map the ERP data to Magento attributes
2. Find new attributes we’re adding
3. Find custom things that are not attributes but something that exists in OXID or the previous platform
4. Additional endpoints for additional features
5. Describe custom logic 
6. Cover how we are handling configurable products and variant logic. Anytime you migrate something to Magento, configurable logic will have complications. Managing composite products should be a separate thing all the time because every eCommerce platform does it differently, and every ERP stores these objects differently—sometimes it’s present in ERP, sometimes it’s not, or it’s mixed; it can be anything
7. Describe changing parents or deleting configurable products 
8. Explain changes to configurable product price settings and additional features that weren’t in the original scope, e.g., how to return data, category-product relation, .NET requests to eCommerce, etc.
9. Oxid API source code analysis
10. Provide suggestions on how we can do things significantly differently that require changes on their side and might be worth it for excellent performance or future expansions—something we could not suggest if we didn’t know how it worked. 

Here’s an example of things that get overlooked—we learned from this analysis that a delete value gets passed in fields such as price, meaning different things in each condition. Sometimes, it means we need to remove a discount, do nothing, or unassign a variant from the parent and delete the parent. Those are the kinds of things you want to address before the launch.

The scenario we wanted to avoid is scrambling before the go-live to figure out what it is and ending up reading the source code anyway.

In our documentation, there are also validations on different fields, e.g., descriptions of delete value behaviors, how the images get updated, how the positioning works, the difference between update and first save, and many other things. 

Results

The migration from OXID to Magento significantly enhanced our client’s eCommerce. We ensured a smooth transition of the client’s extensive product catalog, integrating advanced functionalities seamlessly within Magento without losing the core business operations. 

Conclusion

The migration journey, while complex, is pivotal for businesses seeking to leverage the full potential of their eCommerce store. Successful migration can be achieved through careful planning, comprehensive analysis, deep coverage of the current ecosystem, and suggestions for the target ecosystem. Ensure that a transition to Magento preserves your store’s unique functionalities and enhances them within the new framework!

Are you planning to migrate your store? scandiweb’s experts can execute a detailed analysis of legacy business processes and prepare in-depth documentation from scratch to help you get started and get where you want to be. Drop us a message, and we’ll get back to you shortly to set up a free consultation.

Share on: