--- title: 'Installation, Uninstallation, and Data Cleanup | Shopware Community Hub' description: >- Learn how to plan installation, uninstallation, reinstallation, and data cleanup so extension lifecycle behavior stays stable and transparent. canonical_url: >- https://hub.shopware.com/learn/unit/installation-uninstallation-and-data-cleanup --- - Reliably plan and test the full extension lifecycle. - Implement installation, uninstallation, and reinstallation in a stable way. - Design data cleanup transparently and merchant-friendly. - Handle own tables, custom fields, and CMS elements responsibly. # Installation, Uninstallation, and Data Cleanup An extension lifecycle does not stop after the first installation. Merchants may install, activate, deactivate, update, uninstall, reinstall, or completely delete extension data. Each of these steps affects trust. If installation fails, the merchant cannot start. If uninstallation leaves broken storefront content behind, the shop may look damaged. If cleanup deletes business-critical data unexpectedly, the extension becomes a risk. In this unit, you will learn how to think about installation, uninstallation, reinstallation, and data cleanup as part of the product experience. ## The Extension Lifecycle Is Part of the Product The uninstallation and data cleanup documentation states that extensions must be installable and uninstallable without errors. This includes more than the first install. A Store-ready extension should handle lifecycle operations predictably: - install - activate - deactivate - update - uninstall - reinstall - completely delete extension data where the merchant chooses that option The important mental model is this: > Lifecycle behavior is not background technical work. It is part of the merchant's confidence in the extension. If a merchant cannot safely remove or reinstall an extension, they may hesitate to use it in a production shop. ## Install and Activate Should Prepare the Extension Safely During installation and activation, an extension may need to prepare data, register entities, or create configuration. The plugin lifecycle documentation`. For plugins, these lifecycle methods help separate different responsibilities. For example: - `install()` can prepare data that is needed before activation. - `activate()` can enable behavior that should only run when the plugin is active. - `deactivate()` can disable behavior without necessarily deleting data. - `update()` can handle non-database adjustments for a new version. - `uninstall()` can remove or deactivate data when the extension is removed. The exact implementation depends on the extension type and use case. The principle is the same: lifecycle logic should be intentional and testable. ## Uninstall Does Not Always Mean Delete Everything Uninstallation has two different merchant expectations: - Keep extension data. - Completely delete extension data. When the merchant chooses to keep extension data, persistent data created by the extension should remain. This is useful when the merchant wants to reinstall later or keep configuration and historical data. When the merchant chooses to completely delete extension data, the shop should be restored as if the extension had never been installed, except where business-critical entities must be preserved. This distinction is important. "Clean up" does not mean blindly delete everything. For example, if an extension created a payment or shipping method that has already been used in orders, deleting it may damage historical order data. In such cases, deactivation can be safer than deletion. ## Handle Extension-Owned Data Responsibly Partners should know which data belongs to their extension and what should happen to it during uninstall. Examples include: - custom tables - extension-owned entities - configuration values - custom fields - CMS elements - media folders or uploaded media - payment or shipping methods - generated storefront content The cleanup behavior should match merchant choice and data risk. For a complete delete option, the documentation expects extension-created tables and data to be removed where appropriate. CMS elements added by the extension should also be removed. For custom fields, removing the association may be the correct step while values can remain in core storage. The important question is: > Which data can safely be deleted, and which data must remain because the merchant's shop history depends on it? ## Reinstallation Should Be Tested Reinstallation is often where lifecycle problems become visible. An extension may install successfully once, but fail after uninstall because old data, configuration, custom fields, or CMS references still exist in an unexpected state. Before submission, partners should test: - install on a clean shop - activate and use the extension - deactivate the extension - uninstall while keeping data - reinstall after keeping data - uninstall with complete data deletion - reinstall after complete deletion - storefront behavior after uninstall - administration behavior after uninstall This test path helps catch assumptions that only appear after the first lifecycle loop. ## Store Review Looks at Lifecycle Stability Store Review checks whether installation, uninstallation, and related behavior are stable. The documentation notes that install, uninstall, and reinstall must complete without exceptions. It also states that there should be no 400 or 500 errors during install or uninstall unless they are clearly tied to a documented API call. For partners, this means lifecycle behavior should be part of the pre-submission checklist. It is not enough to test only the happy path after the extension is already active. ## Example: Cleaning Up a CMS Element Extension Imagine a partner builds an extension that adds a custom CMS element for landing pages. During install, the extension makes the element available. Merchants then use it in Shopping Experiences. During uninstall, the partner must think carefully: - What happens to Shopping Experiences that used the CMS element? - Does the storefront still work after uninstall? - Can the merchant keep extension data if they plan to reinstall? - What should happen when the merchant chooses complete deletion? - Are CMS element references removed or handled safely? This is why lifecycle testing needs real usage, not only install and uninstall commands. The extension should be tested after merchants have actually configured and used it. ## Common Pitfalls ### Deleting Business-Critical Data Too Aggressively Data connected to real orders, payments, shipping, or merchant history may need to be deactivated or preserved instead of deleted. ### Ignoring the Keep Data Option If the merchant chooses to keep extension data, uninstall logic must respect that decision. ### Testing Only the First Install Lifecycle issues often appear after update, uninstall, reinstall, or complete deletion. ### Leaving Broken Storefront References Behind After uninstall, Shopping Experiences and storefront pages should continue to work. Broken CMS elements or missing assets can damage the customer-facing shop. ### Treating Cleanup as an Afterthought Cleanup should be designed together with the data model. It is much harder to make cleanup reliable after the extension has already created unclear ownership boundaries. ## Summary - Installation, uninstallation, reinstallation, and data cleanup are part of the merchant experience. - Store extensions should install, uninstall, and reinstall without exceptions or unexpected HTTP errors. - Merchants need a clear difference between keeping data and completely deleting extension data. - Extension-owned tables, custom fields, CMS elements, and generated data should be handled responsibly. - Lifecycle behavior should be tested after realistic use, not only on a clean install. Next, you will look at code quality, logging, and packaging so the extension can be reviewed and shipped in a maintainable way.