In short and in plain language
A shop can close. But its data stays for a long time. You must keep bills for eight years. Some books even for ten years.
After the last sale, people still send things back. Or they get money back through their bank. So the shop stays open for reading for a while.
Then the data goes into an archive. You must be able to read the archive without the shop. Only then is the server turned off.
Customer data that you no longer need is deleted. The name of the shop on the web is called a domain. Keep the domain. If you do not, a stranger can buy it.
A shop rarely ends with one clean cut. More often a second shop is merged into the main one, a product range moves to another platform, or a business gives up mail order at the end of the year. The last sale is quickly done: checkout off, notice page on. The work that follows takes longer. Books and records must be kept for ten years, accounting vouchers such as invoices for eight years and other tax-relevant documents for six years (§ 147 AO). Customers still send goods back, have direct debits reversed and report defects. And a deleted .de domain that carried sales for years is open for anyone to register after a 30-day grace period (DENIC). This article describes how a shutdown runs in four phases: from the last sales day through a read-only phase and a verifiable archive to deletion. It shows which data has to stay and for how long, how the tax authority may access archived data, what happens to customer data and why the domain, payment service, servers and access need a fixed order. Individual tax questions, such as the exact start of the retention period for your documents, belong with your tax advisor. This article covers the technical and organizational framework.
Key takeaways
- Books and records must be kept for ten years, accounting vouchers such as invoices for eight years and other documents for six years (§ 147 AO). Each period starts at the end of the calendar year in which the document was created.
- After the last sale the shop stays in read-only mode for a while: the withdrawal period is 14 days (§ 355 BGB), and customers can reclaim SEPA direct debits for up to eight weeks after the debit (§ 675x BGB).
- During a tax audit the authority may inspect the system, request evaluations or demand an export (§ 147 Abs. 6 AO). After a system change, a machine-readable data carrier is sufficient only once the fifth following calendar year has ended.
- An archive replaces the running shop: structured export, reconciliation against the database, checksums, two storage locations and a documented read test. Only then are servers and services removed and all access revoked.
- Customer data without a retention reason is deleted, for example accounts without orders, wish lists and newsletter lists (Art. 17 GDPR). Invoice data stays until the period ends but is blocked for any other use.
- The domain stays registered and redirects with 301 or 308, for at least a year according to Google (Google Search Central). A deleted .de domain can be registered by anyone after a 30-day grace period (DENIC).
Shutting down does not mean deleting
Anyone closing a shop thinks of the visible parts first: home page, cart, checkout. These are switched off quickly. What remains afterwards is less visible and lasts longer. Orders, invoices, payment journals and customer accounts sit in the shop database, vouchers as PDF or XML in the file system, payment transactions with the payment service provider and shipment data with the carrier. Part of it is subject to retention duties, another part has to be deleted under data protection law as soon as it is no longer needed. Getting both right at the same time is the real task of a shutdown.
A sequence of four phases has proven itself. On the last sales day the checkout closes and the shop shows a notice page. In the read-only phase, returns, refunds and inquiries about the last orders are handled while the data stays unchanged. Then the data subject to retention moves into an archive that can be read without the shop, and the system is taken down. At the end come deletion runs that follow the periods of the individual documents, not the date of the closure. If you only want to clean up test systems and side installations, the approach is described in the article on forgotten test sites and stale subdomains. This article is about the production shop itself.
| Phase | Starts with | Ends with | What keeps running |
|---|---|---|---|
| Last sales day | announcement to customers | checkout switched off | shop, payment service, shipping, mailbox |
| Read-only phase | the first day without orders | completed returns, refunds and chargebacks | admin with a few accounts, payment service, mailbox, domain |
| Archive | the verified export | expiry of the longest retention period | archive storage, domain with redirect |
| Deletion | expiry of each period | the deletion log | only the log |
After the last sale: the read-only phase
Contracts do not end with the last sale. Consumers can withdraw from a distance contract, the withdrawal period is 14 days (§ 355 BGB), and for the purchase of goods it usually only starts when the goods have reached the customer (§ 356 BGB). If proper information about the right of withdrawal was missing, the right expires at the latest twelve months and 14 days after that point (§ 356 BGB). Claims for defects in ordinary goods become time-barred two years after delivery (§ 438 BGB). For each of these periods the business needs access to the order, to the payment channel and an address at which customers can reach it.
Chargebacks come on top. With a SEPA core direct debit, the customer can have the amount refunded by their bank without giving reasons, provided they request it within eight weeks of the debit (§ 675x BGB). For unauthorized payments they can still notify their bank up to 13 months after the debit (§ 676b BGB). Such refunds reach the merchant as returned debits. Anyone who closes the merchant account with the payment service provider too early can neither trace nor document a chargeback, and a refund after a withdrawal can no longer be paid out through the original payment channel.
Technically, the read-only phase means: checkout is off, the data stays unchanged and only a few people still work in the admin. In Shopware a sales channel can be deactivated temporarily or put into maintenance mode. The frontend then only shows the stored maintenance page layout, and selected IP addresses keep access via an allowlist (Shopware documentation). The maintenance page becomes the notice page: it states the closure, the new address of the product range if there is one, the way to return goods and a contact address. If the business continues, the legal notice belongs on this page as well, because the mandatory information applies to commercial digital services that are usually offered for a fee (§ 5 DDG).
In maintenance mode customers can no longer reach their account either. If the account offers invoices for download, announce beforehand until when documents can be retrieved and how customers get a copy afterwards. The law sets no fixed end for the read-only phase. It lasts until the last return is handled, the last refund paid out and no transaction is open with the payment service. During this time security updates continue, because an admin that is online and holds customer data remains a target even when nobody orders anymore. Shopware maintenance therefore does not end on the last sales day, but when the system is taken down.
- Switch off checkout and order emails, switch on a notice page with contact, return route and legal notice
- Limit admin access to the people who handle returns, refunds and inquiries
- Keep the merchant account with the payment service provider open until no refund and no chargeback is pending
- Keep looking after the mailbox and phone line, prepare reply templates for withdrawal, defect and invoice copy
- Stop product feeds, marketplace connections and ad campaigns so that no ad leads to a closed checkout
- Continue security updates, backups and monitoring until the system is taken down
What has to remain: six, eight and ten years
The tax retention duties are set out in § 147 of the German Fiscal Code (Abgabenordnung). Paragraph 1 lists the documents: books and records, inventories, annual financial statements and the organizational documents needed to understand them, business letters received, copies of the letters sent, accounting vouchers and other documents insofar as they matter for taxation. Paragraph 3 assigns the periods: books and records ten years, accounting vouchers eight years, the other documents six years (§ 147 AO). For merchants, the German Commercial Code names the same three periods (§ 257 HGB), and under the VAT Act a copy of every invoice issued has to be kept for eight years (§ 14b UStG).
In this version, the eight years for accounting vouchers have applied since January 1, 2025, namely to all documents whose retention period under the version in force until the end of 2024 had not yet expired (Art. 97 § 19a EGAO). Deletion concepts written before 2025 should be checked against the current wording at this point. For delivery notes received or sent that are not accounting vouchers, retention ends when the invoice is received or sent (§ 147 AO).
For a shop the assignment can roughly be made like this: invoices, credit notes and cancellation invoices are accounting vouchers with an eight-year period (§ 147 AO). Order confirmations, shipping notifications and correspondence with customers and suppliers can be business letters with a six-year period. Payment journals, exports to accounting and order lists that serve as primary records can be records with a ten-year period. This last group in particular depends on how the business does its bookkeeping. If each invoice is passed to accounting individually, accounting holds the record. If the shop is the upstream system from which only totals are taken over, part of the record sits in the shop itself. This classification is made by the tax advisor, not by IT.
The period does not start on the day a document is created, but at the end of the calendar year in which it was created (§ 147 Abs. 4 AO). An invoice dated March 15, 2026 therefore has to be kept until the end of December 31, 2034. For books, the year of the last entry counts; for the annual financial statements, the year in which they are prepared: if the statements for 2026 are prepared in 2027, their period runs until the end of 2037. And even then it is not automatically over. The retention period does not expire insofar and as long as the documents matter for taxes whose assessment period has not yet expired (§ 147 AO). A deletion run therefore works with an earliest deletion date per document, and before a year is deleted, the tax advisor is consulted.
Not tax advice
The tax authority's data access
For electronically created documents, retention means more than storage. If the documents were created with a data processing system, the tax authority may access them in three ways during a tax audit: it can inspect the stored data and use the system itself for the audit, it can request that the data be evaluated by machine according to its specifications, or it can have the data transferred in a machine-readable format (§ 147 Abs. 6 AO). If the data is held by a third party, such as an archive service, that party has to allow inspection, evaluation or transfer. The taxpayer bears the costs (§ 147 Abs. 6 AO).
For a shutdown, the last sentence of this paragraph is decisive. After a change of the data processing system or after moving the data subject to retention out of the production system, it is sufficient to keep the data only on a machine-readable and machine-evaluable data carrier once the fifth calendar year following the change has ended, provided no tax audit has started yet (§ 147 Abs. 6 AO). If you shut down the shop in 2026, a data carrier is therefore enough from 2032 onward. Until then, inspection and evaluation according to specifications must remain possible, meaning a way to display and filter the data with its structure.
This leads to a choice between two routes. The first keeps the old shop system running in read-only mode, with all the updates, licenses and server costs that come with it. The second moves the tax-relevant data into an archive that allows inspection and evaluation without the shop, for example structured exports with a field description and a tool that can read and filter them. Which form of data access is required in a given case is a tax question. That the data has to be available at all times during the whole period, readable without delay and evaluable by machine is stated in the law (§ 147 Abs. 2 AO). A folder of PDF invoices does not allow any evaluation of the order data, and a database copy without a working system displays nothing at all. The taxpayer provides the tools needed to make the data readable at their own expense (§ 147 Abs. 5 AO).
For e-invoices there is an additional requirement on form: at least the structured part has to be kept so that it is intact in its original form (BMF letter of October 15, 2025). So the structured file itself is archived, not just a view of it. How shops prepare for this during normal operation is described in the article on e-invoicing from 2027. For a shutdown this means: the XML files go into the archive unchanged, and the PDF view is added as a reading aid.
An archive instead of a read-only shop
A shop that keeps running in read-only mode for years costs money and remains a risk. The platform needs security updates, the PHP version reaches end of life, extensions lose their license or their vendor, and every update can damage read access to old data. In most cases the archive is therefore the better route. It separates the data subject to retention from the system that created it and makes it readable without that system. The read-only phase then lasts weeks or months, not years.
An archive is not a backup. A backup captures a system state so that it can be restored, and it is overwritten according to fixed rules. An archive keeps selected documents unchanged until the end of their period. A backup of the closed shop also contains everything, including data that should have been deleted long ago. How backup and retention can be kept apart during normal operation is described in the article on GDPR-compliant backup and retention. In a shutdown this separation becomes a one-time, verified export.
Define the scope
Clarify with the tax advisor which shop data counts as vouchers, records or business letters. The result is a list of tables, files, fields and the earliest deletion date per group.
Export in structured form
Export orders, line items, invoices, credit notes and payment transactions as CSV or XML with a field description, and take over voucher files as PDF and e-invoices as original XML.
Check completeness
Reconcile voucher numbers against the database without gaps, compare monthly totals with accounting and resolve differences before the shop is taken down.
Checksums and storage
Create a checksum for every file, store the archive encrypted in two separate locations and document keys, formats and how to read it.
Read test before removal
Open the archive on a computer without the shop system, look up an invoice, produce a monthly evaluation and log the result. Only then is the server taken down.
Clarify with the tax advisor which shop data counts as vouchers, records or business letters. The result is a list of tables, files, fields and the earliest deletion date per group.
Export orders, line items, invoices, credit notes and payment transactions as CSV or XML with a field description, and take over voucher files as PDF and e-invoices as original XML.
Reconcile voucher numbers against the database without gaps, compare monthly totals with accounting and resolve differences before the shop is taken down.
Create a checksum for every file, store the archive encrypted in two separate locations and document keys, formats and how to read it.
Open the archive on a computer without the shop system, look up an invoice, produce a monthly evaluation and log the result. Only then is the server taken down.
The read test decides whether the archive holds up. An export that nobody has opened is the same gamble as a backup that nobody has restored. Why restore tests need fixed dates is explained in the article on backup strategies for online shops. For an archive this applies across the whole period: formats, reading tool and keys must still be available in eight or ten years (§ 147 AO). A yearly read test with a log is the simplest proof, and it can be scheduled together with the yearly deletion run.
Customer data: keep, restrict, delete
The retention duty is not a license to keep everything. Personal data may only be stored in a form that permits identification for as long as is necessary for its purpose (Art. 5 GDPR). With the end of sales, the purpose falls away for a large part of the shop data, and for this data there is a right to erasure as soon as it is no longer necessary (Art. 17 GDPR). The right to erasure does not apply insofar as processing is necessary to comply with a legal obligation (Art. 17 GDPR). That is exactly what the tax and commercial retention duties are.
This results in three groups. Data that can be deleted promptly includes customer accounts without orders, password hashes, wish lists, saved carts, newsletter lists whose consent was tied to the closed shop, and logs whose purpose ends with the shop. For server logs, the rules described in the article on IP address retention in server logs apply. What is kept is the data contained in invoices, vouchers and records, meaning name, address, order lines and payment details insofar as they belong to the voucher. For data that is only needed to defend or enforce claims, the duration follows the limitation periods: the regular limitation period is three years (§ 195 BGB) and starts at the end of the year in which the claim arose (§ 199 BGB).
What is kept may only be processed for that purpose (Art. 5 GDPR). If contractual retention periods prevent deletion, the restriction of processing takes its place (§ 35 BDSG). Apart from storage, such data may then only be processed in narrow exceptions, for example with consent or for the establishment, exercise or defense of legal claims (Art. 18 GDPR). In practice this means: the archived customer data no longer appears in any mailing list, export to third parties or analysis, access is limited to a few named people, and every record carries its earliest deletion date. Updating the record of processing activities and the privacy policy for this period is part of the GDPR updates in the maintenance contract.
That leaves the copies. Backups of the shop contain every record, including the deleted ones. They are deleted as soon as the archive has been verified, or they expire with their rotation. A backup that lies around for years after the shutdown undermines every deletion run. The same applies to staging copies, exports on workstations and database dumps at service providers. A processor has to delete or return all personal data at the choice of the controller after the end of the provision of services, unless there is an obligation to store it (Art. 28 GDPR). This choice should be made in writing and the deletion confirmed in writing.
Keep the domain and redirect it
The domain is the part of a shop with the longest after-effects. Links from comparison sites, forums and old order emails point to it, as do search engine entries and, above all, email addresses. Accounts are often tied to these addresses: with the payment service provider, the carrier, marketplaces, the hosting provider and the domain management itself. Releasing a domain also releases the receipt of all mail to these addresses, including password reset emails.
For .de domains, deletion is followed by a 30-day grace period in which only the last holder or a third party named by them can register the domain again (DENIC). After that it is open for anyone to register on a first come, first served basis (DENIC). An evaluation from December 2023 shows that holders need this period: in the three years before, domain holders recovered just under 0.9 percent of all deleted .de domains within the grace period (DENIC). For a closed shop domain the grace period is not a plan but a last resort. The domain stays registered at least until all accounts have been moved to other addresses, and usually considerably longer.
As long as the domain is kept, it redirects. For a site move, Google recommends permanent server-side redirects such as 301 and 308 (Google Search Central) and advises keeping them as long as possible, generally for at least a year (Google Search Central). From the users' point of view, a redirect without a time limit would be ideal. If the product range moves to another shop, every old product and category URL leads to its counterpart. If there is none, it leads to a matching category or to the notice page. Which status codes fit when and how redirect chains are avoided is covered in the article on 404 errors and broken links.
Three technical points are easily overlooked with redirects. First, a redirect from https addresses needs a valid certificate, otherwise visitors see a warning instead of the target. Managing the SSL certificates therefore does not end with the shop. Second, after the server is taken down, DNS records may still point to old addresses. Such records are deleted or changed before someone else takes over the address. Third, the domain should be locked against changes at the registrar, and the renewal invoice should go to a mailbox that someone still reads after the closure. Registrar lock and expiry dates are covered in the article on DNS maintenance for shops.
Switching off in the right order
After the domain come the services attached to the shop. Here the order matters, because some services are still needed after the closure, while others cause costs or collect data as long as they run. As a rule of thumb: whatever generates new orders or visitors goes first. Whatever handles returns, refunds and chargebacks goes last.
- Advertising and feeds: stop campaigns, product feeds, price comparisons and marketplace connections on the last sales day.
- Order channels: switch off checkout, interfaces for phone or wholesale orders and automatic reorders.
- Marketing: end newsletter sending, reminder emails and review requests, and handle the recipient lists under the rules for customer data.
- Shipping: keep the return address and return labels until the withdrawal periods have ended, then close the business customer account.
- Payment service: export transaction reports into the archive, cancel only when no refund and no chargeback is pending.
- Inventory management and accounting: reconcile the last transfers, switch off the interfaces and revoke their credentials.
- Server and hosting: take down only after the archive read test, and have the hosting provider confirm the deletion.
Taking down the server means more than canceling a machine. Database, file system, snapshots, backups at the hosting provider and copies at service providers go on a list, and for each entry it is decided whether it is deleted, returned or moved into the archive. DNS records that point to the old server are removed in the same step. A record that points to an address that has become free invites a takeover, as the article on stale subdomains describes.
Finally, access is revoked, and completely so: admin accounts in the shop, API keys for payment, shipping and inventory interfaces, SSH keys, FTP accounts, access for agencies and freelancers, and accounts with the domain management and hosting provider that are no longer needed. Keys that live on in other systems are revoked rather than just deleted. The approach is described in the article on rotating API keys, the list of places where access is created in the article on offboarding and access inventory. If the entire business ends with the shop, the discontinuation also has to be reported to the competent authority (§ 14 GewO).
The shutdown plan at a glance
The following overview summarizes the steps. It is ordered by events rather than calendar dates, because the length of the read-only phase depends on returns and the deletion dates depend on the year in which the documents were created.
| When | Task | Evidence |
|---|---|---|
| Before the last sales day | Inform customers, announce invoice retrieval, agree the archive scope with the tax advisor | Announcement, list of data groups |
| Last sales day | Switch off checkout, feeds and advertising, switch on the notice page with legal notice | Screenshot with timestamp |
| Read-only phase | Handle returns, refunds, chargebacks and inquiries, continue updates | List of open cases, empty at the end |
| Archive acceptance | Export, reconciliation, checksums, read test | Test log, checksum list |
| Removal | Cancel services, take down the server, revoke access, clean up DNS | Cancellation and deletion confirmations |
| After each year end | Deletion run for documents whose period has expired, archive read test | Deletion log, test log |
The domain runs alongside this list. It stays registered and redirects as long as links, search results or emails point to it. A decision to release it is made at the earliest after the first year of redirects (Google Search Central) and only once all accounts have been moved to other addresses.
What maintenance takes over in a shutdown
A shutdown is a project with a few weeks of work and many years of aftercare. As part of maintenance we take over the technical side: we keep the shop up to date and reachable during the read-only phase, export the data defined with your tax advisor, check it for completeness, store the archive with checksums in two locations and document the read test. How backup, storage and restore work with us is described on the backup service page.
Read-only operation
Checkout off, notice page on, updates and monitoring keep running until the last case is closed.
Archive
Structured export, reconciliation against the database, checksums and two separate storage locations.
Deletion concept
Earliest deletion date per data group, a yearly deletion run and a logged read test.
Domain
Redirects per URL, a valid certificate, registrar lock and cleaned-up DNS records.
Services
Cancel feeds, shipping, payment service and interfaces in the order of the open periods.
Access
Revoke and document admin accounts, API keys, SSH and service provider access completely.
After the removal, a small and predictable task remains: the yearly read test and the deletion runs once periods expire. Both can be agreed as fixed dates in an SLA maintenance contract, as can the domain, certificate and redirects. What drives the effort in detail is shown in the article on shop maintenance cost drivers. Questions about how your documents are classified and when the periods start are answered by your tax advisor. We implement the answers technically and record when which data will be deleted.
Sources
Related Articles
Custom Mail Templates in Your Shop: Where Updates Stop
Shopware changed its order confirmation three times in fall 2026, but customized templates kept the old version. How to check mail templates after updates.
What Does Shop Maintenance Cost? The Key Cost Drivers
What shop maintenance costs depends on extensions, custom code, integrations and response time. How to plan a 2027 maintenance budget you can justify.
Week 53 and Year End: Avoiding Date Errors in Your Shop
January 1, 2027 still falls in week 53 of 2026. How to check week formats, time zones, number ranges, holidays and promotions in your shop before New Year.