Preparation for going live
Edit on GitHubDon't risk your go-live
The preparation steps listed here are mandatory because they’re crucial for the success of your go-live. We strongly encourage you, customer or partner, to complete these steps where applicable because we won’t be able to resolve issues related to steps not completed in time. Make sure that your project plan contains the tasks related to the go-live checklist and allocates enough time for their completion.
This document describes how to prepare a Spryker project for going live.
We’ve divided the preparation into approximate timeframes. Feel free to copy this to your project management software and adjust to your needs. Make sure that all of the following tasks are completed at least one week before going live.
Eight weeks before go-live
| ID | CATEGORY | NAME | DESCRIPTION | NOTE |
|---|---|---|---|---|
| GEN-01 | General | Share go-live plan | Inform your Partner or Customer Success Manager about your go-live date and time. Create a Go Live Announcement case in Support Portal. |
|
| Update them if plans change. | This is critical for Domain Name System (DNS) switching and the hypercare phase we provide before and after go-live. | |||
| CLO-01 | Cloud | Ensure a network diagram | Ensure a network diagram is available for quick reference to explain the setup if needed. | Sample of the diagram. |
| CLO-02 | Cloud | Third-party systems integration | Double-check that all Virtual Private Cloud (VPC) peering and Site-to-Site Virtual Private Network (VPN) connections are monitored and secure. | We don’t monitor connections with external parties. For more details, see site-to-site VPN. |
| CLO-03 | Cloud | Third-party systems integration | Make sure that routing works as expected and no internal resources are accidentally exposed via the site-to-site VPN or VPC peering setup. | |
| CLO-04 | Cloud | Evaluate DOS and DDOS prevention (frontend) | Check your concepts for denial-of-service (DOS) and distributed denial-of-service (DDOS) prevention or mitigation, and check with relevant vendors for products that fit your needs and are compatible with SCCOS. | |
| CLO-05 | Cloud | Evaluate DOS and DDOS prevention (backend / Merchant Portal) | Check your concepts for DOS and DDOS prevention in the Back office and Merchant portal. Add basic auth if applicable. | For instructions on implementing basic auth, see Configure basic .htaccess authentication |
| CLO-06 | Cloud | Define a DNS strategy | Define how you want to handle the DNS of the shop’s domain. | If you delegate DNS to Spryker, let us know the date on which to point the domain to your project. |
| CLO-07 | Cloud | Set up whitelisting (security) | IPs of Web Application Firewalls (WAF), proxies, and other security and traffic filtering systems used to route traffic to Spryker are whitelisted. | This prevents these systems to be accidentally blocked by Spryker’s security systems. You can request IPs to be whitelisted via an Infrastructure Change Request on the Support Portal. |
| APP-01 | Application | Activate IP tracking | Activating IP tracking significantly increases chances to mitigate or spot malicious activities such as DOS attacks. You might need to evaluate this from a data protection policy perspective. | |
| APP-02 | Application | Upgrade codebase | Upgrade the project’s codebase to the latest Demo Shop release or at least to 202009.0 release. | |
| APP-03 | Application | Upgrade Twig | Update spryker/twig to version 3.15.2 or later. |
This version introduces important stability improvements. |
| APP-04 | Application | Migrate to MariaDB | Migrate the project’s database to MariaDB if applicable. | |
| APP-05 | Application | Migrate endpoints | Split Zed endpoints as described in Integrating separate endpoint bootstraps if applicable. | |
| APP-06 | Application | Check service naming | Verify that the service naming scheme exactly matches the examples in the sample deploy-spryker-b2c-staging.yml file. | |
| APP-07 | Application | Create a deploy file | Create deploy files for each of your environments. File names must follow the naming convention: deploy.(project)-(environment).yml. For example, deploy.example-staging.yml. |
|
| APP-08 | Application | Define Docker SDK version | Define a Docker SDK version. | |
| APP-09 | Application | Integrate FlySystem | Configure the project to use S3 buckets for storage using FlySystem. | |
| APP-10 | Application | Check S3 bucket import | If you’re using CSV imports, make sure they’re imported from S3 buckets. | |
| APP-11 | Application | Set up S3 bucket (staging) | Connect Staging S3 bucket to the staging environment. | |
| APP-12 | Application | Set up S3 bucket (production) | Connect Production S3 bucket to the production environment. | |
| APP-13 | Application | Implement performance guidelines | Implement performance guidelines. | |
| APP-14 | Application | Implement Jenkins guidelines | Implement Jenkins operational best practices. | |
| APP-15 | Application | Implement publish and sync guidelines | Implement applicable Publish and Sync stability best practices. | |
| APP-16 | Application | Implement general security guidelines | Apply security guidelines. | |
| APP-17 | Application | Implement password security guidelines | Make sure that you don’t have any plain-text passwords, private keys, or API secrets in config files or Git repositories. | |
| APP-18 | Application | Implement credentials security guidelines | Minimize the use of personal credentials and use separate work-specific accounts per envrironemnt. We highly recommend employing Centralized Credential Management to securely store and manage these credentials. | |
| APP-19 | Application | Implement secrets rotations | Secrets, like API tokens, should be rotated regularly. Outline and test rotation strategies to prevent issues during live operation. | |
| APP-20 | Application | Install internal security updates | Install all the security updates from all Spryker packages. | |
| APP-21 | Application | Install external security updates | Install all the security updates from all the external packages. | To check if your project modules require security updates, you can use the security checker. |
| APP-22 | Application | Perform compliance and legal checks. | To ensure the platform complies with relevant legal and regulatory requirements, especially for international operations, consult with your legal team. Make sure to check guidelines for GDPR compliance. | |
| APP-23 | Application | Set up Access Control List (ACL) | Prepare the Back Office ACL setup for users to be able to access and manage the shop during live operation. | For instructions on how to configure ACL, see Users and rights overview. |
| APP-24 | Application | Set up DB logs strategy | If the application is writing logs into the DB, develop a strategy on regularly rotating or truncating these logs to avoid large table sizes that can affect the application’s performance. | spy_oms_transition_log is used to log state machine transitions by default. |
| APP-25 | Application | Evaluate and implement payment tips | Check if you can implement redundant payment options so that the payment system keeps working even if one of the options fail. | |
| TES-01 | Testing | Test deployment | Run deployment tests locally to ensure the application can be installed and configured as expected. For instructions on deploying locally, see Simulating deployments locally. | Criteria: Deployment executes without errors, and the application operates as expected in a test environment. |
| TES-02 | Testing | Test payment | Before deploying payment options, test payment end-to-end flows locally. For more information, see HowTo: Debug payment integrations locally. | Criteria: All payment methods process payments without errors. Test both positive and negative cases such as handling a rejected payment. |
| TES-03 | Testing | Perform UAT | Perform User Acceptance Testing (UAT) to validate the functionality and user experience from an end-user perspective. Collaborate with stakeholders to create UAT scenarios for main business flows, execute tests, and gather feedback. Verify that the platform application works properly on supported devices and browsers. | |
| SEO-01 | SEO | Set up redirects | If you’re migrating from another shop or project to Spryker, and the domain is already point to a live shop, prepare a migration plan to phase out the old project and phase in the new one. Check with your SEO experts on the strategy for your content and search engine results. | |
| SEO-02 | SEO | Implement SEO best practices | Review and implement the best practices per Basic SEO techniques to use in your project. | |
| TR-01 | Training | Prepare internal training | Prepare role-specific enablement training for all internal users of the platform. | These may include: Back Office administrators, support assistants and agents, marketplace operators, merchant portal users. |
| TR-02 | Training | Prepare external training | Prepare trainings for external users, such as those interacting with the platform via APIs and third-party systems. | These may include API documentation. |
| TR-03 | Training | Prepare customer training | Make sure your customers are aware of the changes that are to be introduced. Besides striving for good user experience and transparency, consult with your legal team about any obligations in that regard. |
Four weeks before go-live
| ID | CATEGORY | NAME | DESCRIPTION | NOTE |
|---|---|---|---|---|
| GEN-02 | General | Prepare a rollback strategy | Prepare everything for recovering from unforeseen issues after deploying the project. | |
| CLO-08 | Cloud | Set up APM | We highly recommend setting up an Application Performance Monitoring (APM) system. | APM tools help you identify performance bottlenecks in your application. |
| CLO-09 | Cloud | Establish a post-launch monitoring plan | To watch the system’s performance and configure alerting mechanisms, establish a robust post-launch monitoring plan. To ensure effective investigation in case of security incidents, we recommend configuring logs to gather in a centralized SIEM system. | |
| CLO-10 | Cloud | Set up deploy file | Verify that your deploy file is set up correctly and aligns with your project needs. Verify that your project works and operates the production endpoints. You can set both testing and production endpoints in your deploy file. Your developers need to mock a “live” operation of the project with its production endpoints by adjusting their local host entries. | |
| CLO-11 | Cloud | Deploy production environment | Deploy the production environment regularly. This lets you detect potential issues early enough to fix them before going live. For instructions, see Deploying in a production environment. Make sure to test all recipes. | |
| CLO-12 | Cloud | Prepare a DNS strategy | Decide how you want customers to access your shop and verify that you control access and can manage the DNS. For example, the domain of your shop is spryker.com, but you want customers to access the Storefront at www.spryker.com. For details on how to set up DNS, see Set up DNS.- Optional: Delegate DNS to Spryker. - Make sure Transport Layer security (TLS) certificates are provisioned. If you delegate DNS to Spryker, TLS certificates for your endpoints are created automatically. If you want us to create TLS certificates for your endpoints but don’t want to delegate your DNS, request the verification of DNS records through the Support Portal. |
|
| CLO-13 | Cloud | Choose an email service | You can use Spryker’s native mail service or integrate a third-party provider. If you choose the native service, provide the sender email address so we can lift sending restrictions and assist with DNS validation. For more information about the default email service and its restrictions, see Email service. | |
| APP-26 | Application | Prepare and communicate technical debt mitigation plan | Develop a comprehensive plan to identify, address, and communicate strategies for managing technical debt before the system goes live. Make sure that all the stakeholders are aware of missing or incomplete features and agree on the mitigation plan. | |
| APP-27 | Application | Check environment variables | Make sure all the required environment variables and parameter store values are set up. | |
| APP-28 | Application | Prepare DB creation in production | Prepare and implement database creation in production. For example, commit Propel migration for production and update the deploy file to install the database from the committed migration files. | |
| TES-04 | Testing | Test third-party integrations on production | - Collect instructions and requirements from the third-party providers for using services in production mode. - Update integrations and plugins to use production credentials. - Test all functionalities of the integrations and plugins to ensure they work as expected. - Conduct load testing: Simulate real-world traffic on your application to assess its performance under load. This helps identify any bottlenecks that could cause performance issues during peak traffic times. |
In some cases, you may need to comply with specific additional security measures, such as IP whitelisting or port configuration. |
| TES-05 | Testing | Conduct load tests | Test how the platform performs under real-life circumstances. Define the performance acceptance criteria - the sample testing data should be comparable to the size and complexity of the production data. Monitor the application’s performance metrics, such as response times or resource usage, during the tests. Inform us about your load and performance test plans via the Support Portal at least three days in advance and share the results so that we can fine-tune the environment to your requirements. |
Some options to define key metrics: - Historical data: if you have existing traffic data–for example, from Google Analytics - Industry benchmarks: research typical traffic volumes for similar e-commerce sites in your industry - Business goals: Consider target sales, conversion rates, and marketing campaigns to estimate expected traffic |
| TES-06 | Testing | Conduct stress and performance tests | Test your production environment and assess its performance. Because production environments typically employ horizontal auto-scaling, it’s essential to test under expected average and peak loads. These tests enable our team to optimize the environment’s vertical scaling in advance, ensuring that it can seamlessly handle the expected loads from the get-go without any potential delays caused by auto-scaling mechanisms. This proactive approach eliminates the need for post-launch adjustments. For more information, see Environment scaling. Inform us about your load and performance test plans via the Support Portal at least three days in advance and share the results so that we can fine-tune the environment to your requirements. |
Maintain active communication with us. Inform us about your load and performance test plans and share the results so that we can fine-tune the environment to meet your requirements. |
| TES-07 | Testing | Conduct penetration testing | We highly recommend having the project penetration-tested by an independent third-party provider and addressing the identified vulnerabilities. Before conducting a penetration test, inform us at least two weeks in advance by filling out this form. | |
| TES-08 | Testing | Import real data | After importing real data to production, double-check the completeness and accuracy of the migrated data, especially if transitioning from another platform. | Start working with data of realistic size and quality as early as possible. At this point, you must be importing data regularly to all your environments. We recommend working with the same import data across all environments. This significantly simplifies troubleshooting and helps you estimate import performance, leading up to your go-live and helping us with environment sizing considerations. |
| TES-09 | Testing | Test checkout and OMS | Validate the checkout and OMS process: general checkout steps, shipment, payment, OMS. Test all checkout steps, including adding different items to the cart, entering shipping and billing information, selecting a payment method, and placing an order. Also, test the order fulfillment process to ensure that orders are processed and shipped correctly. | |
| TES-10 | Testing | Test payment | WAF and firewall settings in production environments are different from those in non-production ones. Therefore, make sure that all your requests have valid headers. Also, test the functionality of payment integrations that use call-backs or depend on API calls to your application in your production environment. | Criteria: - Make sure the headers of all API requests contain the production mode information to avoid security issues. - Thoroughly test payment integrations that rely on external systems, such as callbacks or APIs, specifically in production. |
| DAT-01 | Data | Prepare a data migration plan | Include all the data that needs to be migrated. | |
| SEO-03 | SEO | Generate sitemap | Generate a sitemap. | |
| SEO-04 | SEO | Prepare and set robots.txt |
Prepare and set the robots.txt file. |
|
| SEO-05 | SEO | Prepare and set static content | Prepare and set all the CMS pages and other content, such as meta tags or links. | |
| SEO-06 | SEO | Set up favicon | Set up favicon. |
Two weeks before go-live
| ID | CATEGORY | NAME | DESCRIPTION | NOTE |
|---|---|---|---|---|
| CLO-14 | Cloud | Set up DNS | Set up DNS. | |
| CLO-15 | Cloud | Configure email. | Configure email boxes and DMARC policy. | |
| GEN-03 | General | Implement code freeze | We recommend having a code freeze at least two weeks before going live. | |
| GEN-04 | General | Evaluate go-live date and preceding tasks | If any of the preceding tasks aren’t complete, postpone your go-live or discuss with us how to complete them in time. DNS changes are especially sensitive to deadlines. Because of the way the DNS system works, any DNS changes take time to take effect. | |
| GEN-05 | General | Set up third-party systems in production mode | Make sure that the third-party systems have been switched to the production mode: Set up production configuration for all the third-party systems (in environment variables). Make sure not to expose secrets in the codebase. | |
| GEN-06 | General | Set up BI and analytics tools in production mode | BI and analytics integrations should not be connected to your production database but rather to the provided read replica. Make sure no external system is interacting with your production database. | |
| GEN-07 | General | Establish a go-live support team | Establish a team that can monitor your go-live process, react quickly to any issues, and work with the Spryker Support or Operations teams. | |
| GEN-8 | General | Define the exact plan for the go-live day | Define the time of deployment. Define the exact steps to be performed, including running Jenkins or other scripts, if needed. Prepare a go-live communication plan: Develop a communication plan to inform stakeholders, customers, and support teams about the launch date and any changes or updates. | |
| TES-11 | Testing | Perform end-to-end testing on production | Test the customer journey with all the third-party systems switched to the production mode. Make sure to cover all important flows: - Customer registration, account management - Main e-commerce flow: search, navigation, checkout, and OMS process - Back Office and Merchant user flows |
|
| DAT-02 | Data | Remove demo data | Remove all the demo data from the environment. The project should only use the real data that will be used after the go-live. Remove all the demo data that comes with the Spryker repository, which includes demo and admin users. Demo users in a live shop pose a significant security risk for your project. | |
| DAT-03 | Data | Import real data | Import real data to the production environment: - Categories - Product data, such as prices, offers, or attributes - Customers, companies, users, merchants - Taxes - Discounts - CMS pages: homepage, CSM blocks, terms & conditions - Custom data - Other data |
Criteria: user journeys are running as expected. There’re no blockers or unaddressed high-priority bugs. All the test cases and checklists prepared beforehand pass or don’t block the release. |
| DAT-04 | Data | Set up translations | Double-check that all the required languages are available. | |
| DAT-05 | Data | Define a glossary update strategy | Define the glossary update strategy. For example, exclude glossary updates during the normal deployment. | |
| DAT-06 | Data | Check emails | Make sure that all emails are correct. Double-check that all the needed data and translations are available. | |
| SEO-07 | SEO | Optional: Set up redirects | Set up redirects. |
Go-live
| ID | CATEGORY | NAME | DESCRIPTION | NOTE |
|---|---|---|---|---|
| TES-12 | Testing | Perform end-to-end testing on production | Perform smoke testing on production. Because its final the stage, test the main business flows and third-party integrations. | |
| CLO-16 | Cloud | Disable email sending restrictions | Disable email sending restrictions. | |
| CLO-17 | Cloud | Remove basic auth | Remove basic authentication from the frontend part and deploy the change. | |
| GEN-9 | General | Run the go-live communication plan | Run the go-live communication plan. | |
| CLO-18 | Cloud | Disable destructive pipeline | Disable the destructive pipeline after a successful go-live. | |
| GEN-10 | General | Disable old system after 72 hours | After pointing the domain name to your Spryker project, some of your customers may still see your old project until the DNS propagation is completed. So, keep it live for at least 72 hours after the migration. |
Don't hesitate to contact us
If your go-live date is near and you need help with any of the tasks described, contact us via your Customer Success Manager right away. If you’re a Spryker partner and unsure who the Customer Success Manager is for our joint customer, reach out to Partner Success Management via the Partner Portal. They will connect you with the right contact for your project.
Thank you!
For submitting the form