Migration from Keitaro

You choose migration at step 2 of the first-run wizard, after HTTPS is connected. It is meant for a new installation. In a panel that is already running, you can view the result and work through the issues, but you cannot start a new migration from a file through the panel.

A suitable archive

Two different kinds of backups are supported:

• Keitaro 10 — a kctl transfers dump migration archive with ClickHouse statistics.
• Keitaro 11.8.3 and 11.10.0 — a completed physical kctl backups backup packed into a single archive. Micator prepares it on its own before the migration. The format, contents and preparation steps are on Keitaro 11 migration.

A regular ZIP with landing pages, a standalone SQL dump and an unfinished backup do not work. The wizard checks the format before it writes any campaigns. Other Keitaro 11 versions are not automatically considered compatible.

Keep the source archive separately. Micator reads it and does not change or delete it. A large archive needs space not only for the downloaded file but also for the pages, the history preparation and the databases. The wizard shows a space estimate, and the history loader checks the free space again.

What is migrated

• Campaigns with traffic for the selected period, and their addresses (aliases).
• Streams, supported filters and actions.
• Traffic sources, affiliate networks, groups and domains.
• Offers, landing pages and suitable hosted page files.
• After the start, the click and conversion history for 90 days (UTC) for the migrated campaigns. It is loaded separately, in the background.

Keitaro users, passwords, administrative API keys and HTTPS certificates are not migrated. The Micator owner is created in the wizard. Certificates for the domains are issued again.

The kept alias lets you keep the path of the ad link. Before you change DNS, check the domain and its assignment in Micator. Migrating the archive alone does not switch traffic away from the old server.

Archive on another server

1. At step 2, expand Migrate from Keitaro («Перенести из Keitaro»).
2. Choose Archive on another server («Архив на другом сервере»).
3. Enter the Archive server IP («IP сервера с архивом»), the SSH port («Порт SSH»), the SSH login («Логин SSH») and the full Archive file path («Путь к файлу архива»). By default the port is 22 and the login is root.
4. Choose password or SSH key login. For a password, you need the user's password on the server. For a key, paste the whole private key; fill in the password field only with the passphrase of the key itself, if the key is encrypted. For a key without a passphrase, leave the field empty. The root password is not an SSH key passphrase.
5. Click Check server («Проверить сервер»).
6. Compare the SSH key fingerprint shown with the key of the server where the archive is stored. The command for checking it is shown right in the wizard.
7. Select The fingerprint matches my server's key («Отпечаток совпадает с ключом моего сервера») and click Download archive («Скачать архив»).

The download runs over SFTP. You can close the tab: the work continues on the server. The Stop («Остановить») button interrupts the download; when you continue, the wizard resumes the same file if the source has not changed. If you closed or refreshed the tab, enter the credentials again: the wizard does not keep them for your next visit.

If you see “The key cannot be read” («Ключ не читается»), check that you pasted the whole private key, including the BEGIN and END lines, and not the public key. For an unencrypted key, clear the password field. An encrypted key needs its own passphrase.

Archive already on the Micator server

1. Choose Archive is already on this server («Архив уже на этом сервере»).
2. Enter the absolute path, for example /var/lib/micator-import/keitaro.tar.gz.
3. Click Check archive («Проверить архив»).

The file must be in one of the allowed directories: /var/lib/micator-import, /var/lib/micator-keitaro, /root, /home, /srv, /mnt, /media, /opt, /data, /backup. The file at this path is not uploaded from the browser: copy it to the server yourself beforehand.

Summary and decisions

After reading the archive, the wizard shows the Keitaro version, the number of objects, the checksum and the period options: 30, 60, 90 or 180 days. The period determines which campaigns are selected based on their traffic; it is not the period of the background history, which uses a separate 90-day UTC window.

Check the additional questions if they appear:

The summary shows how many campaigns will be migrated enabled and how many will stay paused. One campaign can have several holds, so the reason totals can exceed the number of campaigns.

1. Type the word ПЕРЕНЕСТИ (Russian for “migrate”) and click Confirm migration («Подтвердить перенос»).
2. Fill in the team, owner, password and license below.
3. Click Launch tracker («Запустить трекер»).

While the configuration is being written, traffic of the new installation is closed. The wizard migrates the objects and files, checks the result and then opens the traffic. Campaigns with unresolved holds stay paused.

After the start

Open Settings → Migration from Keitaro («Настройки → Перенос из Keitaro»). The tab is available to the owner and the admin. It has the summary, the history state, issue groups and the Download issues · CSV («Скачать замечания · CSV») button.

1. Connect the IP2Proxy database if the campaign rules require it.
2. Expand each hold reason and go to the campaign or page it points to.
3. Fix the settings and check the redirects and the form submission.
4. If the reason has a Check and release the hold… («Проверить и снять удержание…») button, open the confirmation and click Check and release («Проверить и снять»).

After the recheck, campaigns without other holds can turn on. Campaigns you have already changed manually stay under your control. Clicking the button by itself does not remove an unsupported filter and does not fix the page code.

The CSV contains unresolved issues, not a full data archive. More about the background history and old postbacks is on History after migration.

Switching the domains

1. Check several campaigns through the Micator tracking link, including hosted pages and forms.
2. Check the outgoing postbacks of sources and campaigns, external gateways and macros.
3. In the postback wizard, choose the migrated source and network. Give the partner the current Micator postback address, keeping the source secret.
4. Wait for the history of the old clicks you need if conversions are still expected for them.
5. Switch the domains' DNS one at a time. Check new clicks, conversions and the event delivery log.

The historical load does not send accumulated conversions to ad networks by itself. A new valid postback is processed according to the license state. For old Keitaro 11 clicks, the migrated type transition rules also apply; see History after migration.

Error or cancellation

If something fails, the wizard shows the reason. Fix it and click Retry launch («Повторить запуск»). To start a clean tracker, choose Continue without migration («Продолжить без переноса»): the wizard finishes canceling the migration it has already started before it opens the traffic.

Do not delete the source or the working files manually during the operation. You can read the state on the server:

sudo micatorctl keitaro-import --step status

Deleting the downloaded copy in the wizard applies only to the file that Micator downloaded. It does not delete the original on the Keitaro server. While the history uses the file, deleting the copy is blocked.

While the archive is downloading and being checked, tracker startup is unavailable even if all owner fields are filled in. Wait for completion, review the contents and confirm the migration settings. Keep the wizard open until the tracker starts. History then imports on the server in the background; progress appears on the dashboard and migration settings page.