> ## Documentation Index > Fetch the complete documentation index at: https://docs.fynn.eu/llms.txt > Use this file to discover all available pages before exploring further. # Transferring data between environments > Transfer settings, catalogue, plans, customers and other data from one environment of your organisation into another. Data sets, exceptions, repeated transfers and reasons for skipped records. You can copy data between the environments of your organisation. That way you set up and test your catalogue in a Sandbox first and then transfer it into the Live environment. To transfer data, switch to the environment that is to receive it and open **Einstellungen > Übertragungen** (Settings > Transfers). There you start the transfer and choose the source the data comes from. New records are created in the target. Records you transferred before are updated. The source stays unchanged, and a transfer deletes nothing in the target either. A record the target already uses, such as a product with running subscriptions, stays as it is. ## Roles and rights To transfer data you need the Administrator role in the target and, in the source, an active account whose role may read all the data you transfer. If a right is missing in the source, the app names the data sets concerned. You then deselect them or have the right granted to you in the source. You see the entry **Übertragungen** when transferring data is switched on for your organisation and your role has the right "Umgebungen anlegen und löschen" (create and delete environments). All administrators of the target see the transfers into their environment. You can confirm and cancel only a transfer you started yourself. The exception is the transfer that was started for you when your Live environment was created: **Erstellt von** (created by) shows "Fynn-Support" there, and every administrator of the Live environment can cancel it. ## Preview and start Choose the source and the data sets and create a preview. For each part it shows how many records would be created, updated and left out, and it names the reason for every skipped record. Nothing changes in the target until you start the transfer. If it goes into a Live environment, you first type its username. The preview is valid for one hour. After that you create a new one with the same selection using **Vorschau neu erstellen** (create preview again). You stop a running transfer with **Übertragung abbrechen** (cancel transfer). Parts that have not started are then left out, and a part that is running is either completed or rolled back in full. Finished parts stay in the target. Only one transfer runs into an environment at a time. You can [delete data](https://docs.fynn.eu/en/guide/tenant/delete-data.md) in the source and the target again once the transfer has finished. In the same way, a transfer starts only once no more data is being deleted there. ## Data sets A data set brings along the parts of other data sets that its records refer to. The app shows them below the chosen data set as "Wird mitübertragen" (transferred along). A part that comes along transfers all of its records from the source. With the plans you therefore get all products and price plans of the source, but no product groups. ### Settings * **Einstellungen** (settings): accounting and ledger accounts, billing and invoices, payment reminders, customer area, customer page, offers, return debits, the look of PDF documents, and the DATEV client and adviser numbers. * **Steuergruppen** (tax groups): your own tax groups with their tax rates. An existing tax rate is never changed, new ones are added. * **Kontenrahmen** (chart of accounts): missing ledger accounts are created, existing ones only get the new name. The chart of accounts itself (SKR03 or SKR04) changes only in a target that does not bill yet. * **Nummernkreise** (number ranges): format, length and kind, never the counter. If the target has already issued numbers from a number range, its format stays. * **Vertriebskanäle** (sales channels): the settings for customer area, orders, customer portal and documents, the sender name and the switch for sending emails. * **E-Mail-Vorlagen**, **Dokumentvorlagen**, **Layouts und Logos** (email templates, document templates, layouts and logos): a file of the target is never overwritten. * **Mahnregeln**, **Kündigungsgründe** and **Regeln für Rücklastschriften** (dunning rules, cancellation reasons and return debit rules). * **Rollen** (roles): your own roles with their rights. Your own role that somebody in the target already holds stays as it is. With **Team übernehmen** (copy team) the users of the source get an account in the target, with their role from the source and without an email. An existing account in the target keeps its role. Nobody is copied into a Live or Migration environment whose role there would be Administrator or who would be allowed to manage users or API keys. You grant these rights in the target yourself. If the target already bills, because it has an invoice or a running subscription, it keeps its settings for billing, invoice generation, accounting, ledger accounts, DATEV and payment reminders. The email sending of the sales channels, the switches of the email templates, the dunning rules and the return debit rules stay there as well. A transfer from a Sandbox therefore never changes how your Live environment bills and writes to its customers. The preview lists each of these settings with its previous and its new value. ### Catalogue Units, cost centres, custom fields, product categories, products with their translations and price plans, product groups and the plans of the previous plan management. The catalogue brings along the tax groups, sales channels and metrics of the source. Prices are copied with every decimal place. Price plans of individual customers belong to the customers data set. ### Plans, metrics and features **Plans** come with their tiers and the products and quantities of each tier. They bring along all products and price plans of the source. **Metrics** for usage-based prices come with all their versions. A version the target uses is not changed, and no new version follows it there, so its usage data keeps arriving. **Features** come with their assignment to products and price plans and keep their ID, because integrations address them by it. The entitlements of customers to features are not transferred. ### Discounts and commission plans **Discounts** are coupons with their restrictions to products and plans. If the product or plan of a restriction is missing in the target, the whole coupon is left out, so that it does not apply to more there than in the source. In that case, transfer the catalogue or the plans along with it. **Commission plans** come with their rules, the commission settings and the sales representatives with their customer assignments. A plan with a rule for a product that is missing in the target is left out. A sales representative with a user account is only transferred if the same person has an active account in the target. Sales representatives from connected software such as xentral stay in the source. Customer assignments only come along for customers that are already in the target. ### Asset types Asset types with their attributes, statuses, swap reasons, return check items, products and accessories. The assets themselves are not transferred. ### Customers The master data of your customers with email addresses, active addresses, customer group, parent customers, partners, the values of the custom fields and the customer settings for billing, invoices, payment reminders and e-invoices. The price plans of individual customers come along too. Every new customer gets the payment method bank transfer in the target. Other payment methods, SEPA mandates, subscriptions, invoices, balances and customer portal access stay in the source. The customer numbers stay as they are in the source, and afterwards the number range of the target jumps past the highest transferred number. For a customer the target already has, the customer number, DATEV number, currency, external ID and customer type stay. The report names what differs. Customers reach a Sandbox only from another Sandbox, so that no real customer data ends up in a test environment. Into a Live or Migration environment you transfer customers from any environment. Your customers notice nothing of the transfer: no emails or webhooks go out, and no customer is matched against a CRM. If the target has an active webhook for `payment_method.created`, no new customers are created there, because the bank transfer payment method of every new customer would trigger this webhook. The report lists these customers with the reason "An externen Dienst gebunden" (bound to an external service). ## Exceptions The following data stays in the source whatever you select. You set up connections to the outside world in the target yourself. * payment methods, SEPA mandates and bank accounts of your customers * connections to payment providers such as Stripe and PayPal, to DATEV, to CRM and ERP software, to letter dispatch and to the document storage * mail server, your own domains, email domains and sender addresses, the allowed recipient domains of a Sandbox * the creditor ID and the bank account for SEPA direct debits * webhooks, API keys, service accounts and OAuth clients * the notification settings, additional recipients of invoice emails, the countersigner of offers and the websites allowed to embed the customer portal * subscriptions, invoices, payments, postings, orders, offers, dunning letters and month closings * assets, usage data, balances, coupon redemptions, commissions and payouts * the counters of the number ranges and the customer portal access The billing method of an environment is not transferred either. ## Transferring again Every transfer remembers which record of the source belongs to which record in the target. The next time, these records are updated instead of created again. This also works across several environments: a product you transferred from the same Sandbox into a Migration environment and into the Live environment is not duplicated by a transfer from the Migration environment into the Live environment. An example: you have transferred the catalogue from the Sandbox into the Live environment. Weeks later you rename the products "Support" and "Cloud Paket" in the Sandbox. Meanwhile a checkout link in the Live environment sells the Cloud Paket. The next transfer updates "Support" and leaves out the Cloud Paket with the reason "In Verwendung" (in use). You enter the new name there by hand. If there has been no transfer yet, the transfer looks in the target for a record with the same unique key, such as the code of a coupon, a plan or a cost centre, or the external ID of a customer. Products and price plans have no such key. A product you created by hand in both environments therefore exists twice after the first transfer. Transfer the catalogue early and maintain it in the source afterwards, then every product stays linked to its counterpart. A customer without an earlier transfer and without an external ID whose customer number is already taken in the target is left out. Two customers are never merged just because of their customer number. ## Result and skipped records After the transfer, **Ergebnis** (result) shows for each part how many records were created, updated and left out. If a part fails, its changes are rolled back in full, and the parts that need it are left out. The other parts continue. If at least one part finished, the transfer ends with "Teilweise fehlgeschlagen" (partially failed). Under **Ausgelassene Datensätze** (skipped records) every entry has a reason. The list shows up to 5,000 entries per part, and the totals are still correct. | Reason in the app | Meaning | | - | - | | In Verwendung (in use) | The target uses the record, for example in subscriptions, invoices, checkout links, plans, redemptions or commissions, or it already bills and therefore keeps a setting. Change it in the target by hand. | | Verknüpfter Datensatz fehlt (linked record missing) | A record this one refers to is missing in the target, for example the product of a price plan. Transfer its data set along. | | Mehrere passende Datensätze (several matching records) | Several records match in the target, so none is chosen. | | Kundennummer vergeben (customer number taken) | The customer number is already taken in the target, and the customer has no external ID. | | Nummernkreis in Verwendung (number range in use) | The target has already issued numbers from this number range and keeps its format. | | Systemrolle (system role) | System roles such as Administrator are never changed. The entry appears in the report of every transfer of the settings. | | Bereits Mitglied (already a member) | The person already has an account in the target and keeps their role. | | In dieser Umgebung deaktiviert (deactivated in this environment) | The person's account is deactivated in the target and stays so. | | Support-Zugang (support access) | A support access is never transferred. | | Kein Konto in dieser Umgebung (no account in this environment) | The person the record refers to has no active account in the target. | | An externen Dienst gebunden (bound to an external service) | The record belongs to connected software, or the target would trigger a webhook for a new customer. | | Gültigkeit nicht übertragbar (scope not transferable) | The restriction of a coupon cannot be transferred in full. | | Für diese Umgebungsart gesperrt (blocked for this kind of environment) | Customers of a Live or Migration environment into a Sandbox. | | Ungültige Angabe (invalid value) | The target refuses a value, for example because a product has a different type there. | | Rolle mit höheren Rechten (role with higher rights) | With the team, somebody would become Administrator in a Live or Migration environment or be allowed to manage users or API keys. | If source and target have different time zones, the preview shows the note "Abweichende Zeitzone" (different time zone). Points in time such as validity periods are copied unchanged, so a date can look different in the target. ## Copying data when creating an environment You give a new Sandbox or Migration environment data right in the dialog for creating it, see [Copying data at creation](https://docs.fynn.eu/en/guide/organisation/environments.md#copying-data-at-creation). The same data sets and rules as on this page apply. Because the new environment is empty, this transfer runs without preview and without confirmation, and you find it afterwards under **Einstellungen > Übertragungen**.