Preparation for going live

Edit on GitHub
Don'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 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 close and you need help with any of the described tasks, contact us via your Partner or Customer Success Manager right away.