Setting Up a 1C-Bitrix License: Why Production Fails After Migration
The 1C-Bitrix license key is bound to the environment, not to the hardware: the product checks the domain, port, and edition. As long as these parameters match the record in the key, the portal opens normally.
As soon as the environment changes—moving the project to a new server, changing the portal domain, switching to a non-standard port or back to the standard one—the site is considered new, and the system goes into demo mode or returns an error.
On the surface, it looks like “the site is unavailable after migration,” even though the files, database, and settings are in place.
The second class of failures is parameter desynchronization. During migration, files and a database backup are copied, but the key itself and the environment-to-site binding are forgotten: the domain was updated in one place while the old one remained in another.
If several sites run under one license, or a test environment is cloned from production, the discrepancy does not appear immediately but after the first synchronization.
The cost of such a mistake is not a neat notification in the panel but an unavailable portal and broken integrations. Setting up a 1C-Bitrix license here means not reinstalling but bringing the environment to the form that the key recognizes as its own. We explain how this is resolved without downtime.
What Order in Environments Gives You: Stable Updates and Rollbacks
While the test and production environments live on one key and one database, any update turns into a lottery: changes to the core, modules, and permission settings go straight to the live site.
Template or module incompatibility surfaces for visitors, and reverting to the previous state is done manually without any guarantee that the files and database have been restored consistently.
A properly configured 1C-Bitrix license removes this limitation: it is designed for a separate test domain, so updates are first tested on a copy.
We deploy it on a database snapshot, run the core and module update, check key scenarios—ordering, payment, authorization, exchange with 1C—and only then transfer the verified set of changes to the production environment.
Thanks to this, update downtime is reduced from several hours to 10–20 minutes.
Rollback to the previous state takes minutes because a database snapshot and a fixed file version remain before each deployment: recovery does not depend on whether anyone remembers exactly what changed.
A separate effect is a reduction in the number of manual edits. Updates proceed through the standard mechanism, environment settings are documented and repeatable, and the test and production environments differ only in access credentials and data.
Release predictability stops being a wish: every deployment has a plan, a rollback point, and a checklist before publication.
License Activation and Transfer: Which Mode Fits
A 1C-Bitrix license is bound to the domain, project edition, and server—so activating it “as it happens” almost always results in rebinding and site downtime.
The modes differ in how many sites and which environment they cover: you should choose before launch, not after the first migration.
| Option | When it fits | Limitations |
|---|---|---|
| Activation on a single server | one site, one domain | the key is bound to the address; migration requires transfer |
| Transferring the key to another domain | hosting change, new address | downtime window between deactivation and activation |
| Multi-license for several sites | a network of sites, branches | shared site limit; one key for all |
| Isolated environment without external validation | a network with no external access | updates are installed manually, as a package |
The key transfer is done together with the migration: a copy of the database and settings is taken, the binding is deactivated, then activation is performed on the new domain.
It is safer to cover the test environment with a separate license—otherwise the transfer halts the production site.
Changing the project edition is a separate scenario: the edition is selected for the modules that are actually needed, and the update is first installed on a copy.
We check that the catalog, orders, and exchange with the external system work without errors, and only then switch the main site.
In an isolated environment, license validation occurs inside the network, and updates are brought in as a package—this is built into the maintenance policy in advance; otherwise the very first update stalls.
Workflow: From Environment Audit to Handover to Support
We begin work with an audit of the current environment: an incorrect key binding does not break the site immediately—it quietly disables updates and technical support and manifests when a vulnerability needs to be closed. Therefore, we first record the facts, then make changes.
The order below is the same for activation, for transferring a license to another server, and for switching to a multi-site edition.
- Audit of the current environment. We compare the license edition with the actual needs of the site, check the update period, the state of the core and modules, and find traces of past migrations and test copies left by previous contractors.
- Inventory of sites and domains. We collect all domains, subdomains, language versions, and test stands, and mark which are served by one key and which require a separate license.
- License binding scheme. We prepare a map of “key—domain—site—owner.” It immediately shows where a multi-site edition is correct and where a separate key is needed: this removes conflicts when adding new sites.
- Activation and transfer. We bind the key to the domain on the target server, transfer the license when changing hosting, synchronize the license data with the site parameters, and record the rollback point.
- Post-activation check. We run production scenarios: core and module updates, extension installation, forms, payment, exchange with 1C, email sending. We check not the fact of activation but that the license does not break related processes.
- Handover to support. We provide the binding map, the procedure for actions when changing the domain or server, and the renewal process—so support can see what is failing and where, without digging through past settings.
The Set of Diagrams, Accesses, and Policies That Stays with You
The set is needed not “for reporting” but so that a year later no one has to guess which domain is bound to which license and who has the right to transfer it.
We maintain these documents alongside the project code and update them with every environment change, so the client ends up with working documentation, not decorative documentation.
- Environment and site map — a list of environments (development, acceptance, production), bound domains and subdomains, the license edition on each, the number of active sites and users, and the points where the license is already close to its limit.
- Access policies and roles — who has the right to activate, transfer, and change the edition; how the rights of the product administrator, server administrator, and contractor are separated; and the procedure for granting and revoking access when an employee leaves.
- Update policy — the sequence from the acceptance update to the production branch, the maintenance window, the criteria for rolling back to the previous snapshot, and who signs off on the release.
- Recovery instructions — where file and database backups are stored, the depth of recovery points, and the step-by-step procedure for changing the domain or migrating to another server, including re-binding the license.
- List of credentials — activation keys, access to the license management panel, service accounts: where they are stored, who owns them, how they are transferred, and how often they are changed.
- Multi-license scheme — which license covers which project, where using one key for several sites is acceptable, and where it violates the terms and leads to blocking.
- Change log and escalation point — what and when changed in the license configuration, whom to contact in case of activation failure, and what response time we maintain.
We deliver the documents in a format that lives in your repository or knowledge base—they can be edited without us, and a new contractor can get up to speed on the project from them rather than from correspondence.
Case Study: Migrating a Portal to a New Server Without Losing Access
The client’s 1C-Bitrix portal with a personal account area for employees and external contractors was migrating to a new server at the same time as a domain change.
Previously, such work was done through a nighttime shutdown: the database was migrated as a dump, the license remained bound to the old address, and in the morning administrators dealt with a stream of requests from those who could not log in. Downtime reached six hours, and the next day support received several dozen requests.
What Was Changed in Preparation
A database snapshot was taken in advance and deployed on the new server, leaving a replica in continuous synchronization—by the time of the switch, the discrepancy was measured in minutes, not hours.
Group rights, active sessions, and passwords are transferred together with the database, so no one had to re-enter their credentials.
The license was re-bound to the new domain before work began, as a separate step—this is exactly what eliminates repeated activations for employees.
What the Result Was
The switch took 25 minutes in an agreed window instead of six hours, and the entire time the portal responded at the old address with a redirect rather than an error page. In the first day, three requests came to support, and none concerned access.
There were no repeated activations or key reissues for employees: the license moved together with the domain in one go.
A month later, a control migration of the test environment under the same procedure took even less time and required no manual edits. For this portal, migration and domain change became a planned operation with a predictable window rather than an emergency measure.
What to Do If the Key Is Already Bound to the Old Domain
The license key is bound to the domain at the moment of activation, so migration by itself does not break anything—what breaks is the “key plus site” pairing.
If the previous domain is unavailable, the key does not stop being valid, but it cannot be activated at the new address without unbinding it. This is the first thing to separate in your mind: the license and the working copy of the site live separately from each other.
Next, we determine whether access to the previous site remains at least at the level of files and the database.
While the server responds, we take a backup of the directory and a database export before any actions with the license—then the transfer of settings, modules, and user data will proceed without losing the configuration.
If access is completely lost, the only source is the latest backup, the previous hosting provider’s archive, or a copy left with the previous contractor.
Re-activation on the new domain goes through a request to 1C-Bitrix support: ownership of the key is confirmed, the binding to the unavailable address is removed, and then the key is activated again.
In parallel, we check what else is tied to the old domain—licenses of additional modules, email settings, exchange with the accounting system—otherwise some functions will remain non-working while the site appears alive.
The recovery procedure deliberately does not begin with the license. First we bring up a copy at a technical address, make sure the site opens, exchange works, rights and email function, and only then transfer the key and switch the domain.
This keeps the downtime window minimal, and an unsuccessful switch is rolled back without consequences for visitors and search rankings.
Technical Doubts: Keys, Domains, Test Copies
Before license work, the same set of questions usually comes up: how the key will behave during migration, what to do with an expired term, and whether a test copy of the project can be brought up without affecting the production site.
Below are brief engineering answers so that the decision on 1C-Bitrix is made before changes, not after.
A copy, migration to the cloud, and module updates are connected: the wrong order leaves the production environment without updates, and the key gets attached to the wrong site. That is why we plan site separation in advance.
Is a separate license needed for a test copy of the project?
The copy is brought up at a separate address and does not serve visitors. For short checks, a temporary site is enough; for a permanent stand, use its own key, otherwise the separation of sites becomes blurred.
What happens after the license expires?
The site continues to run on the current build but stops receiving module and core updates. Renewal restores access, but first we take a backup and check the compatibility of custom components.
Is the key transferred when migrating to the cloud?
Yes: the license is bound to the project, not to the server. First we bring up a copy in the cloud and check it, then transfer the key and change the site binding.
Can modules be updated in parts?
Yes, module updates are selective: first the core and critical modules, then the rest. With custom components, this allows rolling back an individual step without reverting the entire site.
Let’s Discuss the Task: What We Need from You to Start
To come back with an estimate and work plan rather than clarifying questions, we need just one message with the project inputs.
The more specifically the current licensing environment is described, the more accurately we can state the scope of the stages and the timeline for each.
- License type and edition: single or multi-license, domain or product binding, whether there is an active update key.
- Task statement: activation, transfer to another domain or server, combining several sites under one license, renewal, or investigation of duplicate keys.
- Infrastructure: where the project is hosted, how many environments there are—production and test—and which web server and database it runs under.
- Accesses: administrator in the “1C-Bitrix” panel, registration details with the distributor, access to the server or hosting—at the diagnostics stage.
- Constraints: the window in which migration is allowed without stopping operations, the requirement to preserve search rankings, and an isolated environment for part of the data.
- Point of contact on your side: the person who approves license decisions and accepts the result.
Based on these inputs, we record the work plan and estimate: the sequence of stages, the timeline for each, what we do on our side, and what is required from you.
We separately discuss the rollback procedure—if something goes wrong in the production environment, we restore the previous license configuration without losing access to updates.
Describe the task in free form—we will come back with an estimate and a plan. If a voice call is more convenient, we will schedule a conversation with the engineer who handles such tasks.