Considering moving from an on-premise solution, or alternate cloud hosting solution, to Magento Commerce Cloud?
The great news is the core Magento code does not change. It is possible your Magento solution can be moved into Magento Commerce Cloud with little difficulty. Here are some things to evaluate when considering the move:
1. File System Limitations
The file system on Commerce Cloud is read-only except for the pub/media and var folders. If you have any extensions or custom code that is relying on file system access it is imperative that the code uses the Magento-provided functions rather than pure PHP or PHP framework methods. Attempting to use the non-Magento functions will result in file permission issues.
This is commonly seen in file transfer processes between Magento and 3rd party systems or the generation of log/activity files.
2. Fastly Cache Integration
If your Magento solution is not already integrated with Fastly for CDN and caching, there are a few things to consider. Any code that defines blocks that are not cacheable will cause Fastly to not cache entire pages. This is considered bad practice by Magento. If a block isn’t cacheable, the block should be delivered after initial page load via an AJAX request back to the server. Occasionally we see this in custom code, but more often see this in poorly executed third party extensions.
Fastly does provide a tool for you to verify that the caching is working correctly on your site.
Your current CDN solution will no longer be necessary.
3. 301 Redirects
Commerce Cloud only provides limited redirect functionality by default. Simple redirect rules can be applied to your corresponding YAML file. If your current solution has pattern-based redirects (e.g a legacy system using request parameters to define pages) you will need to reimplement these redirects as VCL snippets to install into Fastly.
4. File System Access
Commerce Cloud requires that server access runs through SSH key exchanges. If you have current integrations or business processes that presumes unfettered access to the server or basic login/password credentials, they will need to be upgraded to use SSH keys. Any processes that are leveraging file copies or basic ftp will need to be revised to instead use sftp to transfer files to and from the Commerce Cloud server.
In the event that your local processes cannot accommodate the more secure ssh key exchange, you will need to revise your Magento installation to pull and push from the Magento side rather from your internal application side.
5. Database Access
Commerce Cloud only allows direct access to the database instance from the application server. To access the database you will need to use your registered SSH key and use SSH tunneling. Tools like DbForge will allow you to setup the SSH tunneling and access that database like you would in normal circumstances.
Database administration can be accomplished through a tool that supports SSH tunneling or by ssh’ing to the application server and using the MySQL cli interface.
6. WordPress
Numerous non-cloud installations still use WordPress for blog content. This is not recommended by Magento due to the security vulnerabilities associated with WordPress and is forbidden within the Commerce Cloud setup. Only in rare circumstances (e.g. you have a team of WordPress experts, use many WordPress extensions, and have significant content separate from the e-commerce solution) would maintaining WordPress make sense.
There are several blog extensions that provide popular blog features and serve as a reasonable replacement for WordPress. If your solution must continue to use WordPress you may need to reorganize your site to ensure WordPress will be installed in a separate server infrastructure apart from Magento Commerce.
7. Domain-based Licensed Extensions
Some extensions limit their use by domain names. This licensing structure is incompatible with Commerce Cloud. Commerce Cloud allows customers to spin up new environments with a few button clicks. Each of these environments will have a new domain name. At a minimum your site will have four domains (production, staging, integration, and local development). If your site has multiple stores and the stores use unique domains, each additional store will be another 4 domains at a minimum.
8. Realtime Integrations
If your application is relying on real-time communications to your ERP or OMS system, you may have been leveraging the fact that your system was within the same LAN (local area network) as Magento. With Magento moved to the Commerce Cloud there will be significant latency issues compare to a LAN connection that may make your solution untenable. You may need to work with the cloud infrastructure team to make special provisions for traffic between your server environment and the cloud environment.
9. Active WAF
The default setup for Commerce Cloud only includes a passive WAF from Fastly. If you have suffered through some DDOS attacks and are using active WAF’s from companies like Cloudflare you have to consider a few options:
a. Subscribe to the Fastly Active WAF in addition to the default options.
b. Setup a double proxy that routes Cloudflare (or like) -> Fastly -> Magento (not recommended by Magento).
c. Forgo your current active WAF setup and work within the passive WAF capabilities
10. Bulk Data Loading
Commerce Cloud does not allow for bulk inserts into the MySQL database using the PHP MySQL interface. If you are bulk inserting data, you will need to configure the YAML file to specifically add the bulk operation permission to the database user.
11. Composer-based Deployments
Commerce Cloud uses GIT and composer to execute deployments. If you have made modifications to the vendor folder (and you should never do this), these changes will be lost on deployment to cloud. The deployed code in the vendor folder will be completely determined by the composer.lock file.
If you have hot fixes from Magento, they will need to be placed in the m2-hotfixes folder. When placed there, the hot fixes will be auto-installed on each deployment.
If you have been disabling extensions by editing the config.php file, you will need to modify a deployment file to make sure that they remained disabled after a deployment. Direct editing of the config.php on the cloud post deployment will not work.
12. Local Development Environments
Lastly, a common misunderstanding for customers new to Commerce Cloud is that the integration environment is where development takes place. Developers should be running the system on their own local environments to take advantage of modern development tools like PHP Storm.
If you don’t already have local development environments, plan to spend some time setting up those environments. This includes a separate GIT repository for tracking all code changes within the standard GITFlow process. Commerce Cloud GIT is not your source code repository, rather it is simply the mechanism for pushing application builds to an environment.