Починаючи з релізу 1.3.1 доступна так звана “РОЗШИРЕНА” версія модуля "Міграція 2", яка трохи більше, ніж повністю базується на методі імпорту “Ubilling live register”, що в свою чергу зумовлює використання “стандартного режиму реєстрації абонента в Ubilling”, з безпосереднім залученням Stargezer'у до цього процесу(що накладє певні обмеження, про які буде сказано пізніше).
Головною відмінністю цієї “версії” мігрувалки є:

• опціональна можливість “повноцінного заселення” абонів безпосередньо в процесі міграції - тобто так - створення населених пунктів, вулиць, будинків прямо “на льоту”
• можливість додавання повної адреси користувача до User-comments, якщо вибрано режим імпорту даних без створення населених пунктів, вулиць, будинків
• навішування тегів за TagID або TagName
• додавання паспортних даних
• додавання User-comments
• вибір IP-мережі за IP адресою NASу абона(якщо вказано)
• неможливість використовувати будь-який інший метод імпорту, окрім “Ubilling live register”

Отож, початок доволі стандартний: вибираємо CSV файл, символа-делімітер та кодування

Власне, базується на структурі для "Міграція 2", але, як вже мабуть зрозуміло - є дещо розширеною
Отож, на скріншоті нижче ви можете бачити всі поля даних, які може бути імпортовано. Так, всі-всі, аж до Target network - це поле і все, що нижче за ним - не є полями імпорту.

Після завантаження CSV файлу ми отримаємо форму з табличкою, в якій будуть дані найпершого рядка і номери, за якими і буде проводитись, власне, маппінг(вибачайте за вміст файлу на скріні - нічого кращого з великою кількістю полів на момент написання цього мануалу не знайшлося…): Нижче, під табличкою, побачимо вже знайомі нам випадаючі списки з номерами наших полів(якраз тому дуже рекомендовано щоб у найпершому рядку вашого CSV файлу містилися саме осмислені найменування полів даних - хоча це і необов'язково).

“Ubilling live register” накладає такі обмеження

• строга вимога до коректності структури файлу імпорту та, власне, імпортованих даних: так, зайві символи-делімітери або “кракозябри” в даних можуть призвести до фатальної помилки в процесі виконання скрипта, яка призведе до зупинки процесу імпорту “десь посеред дороги” і вгадувать потім, які записи було імпортовано, які ні, а які було імпортовано частково - вам доведеться самостійно, витративши чимало часу(це гарантовано на 88.88%)
• неможливість імпортувати всю вашу БД з CSV файлу розміром кілька гіг: так, оскільки імпорт кожного запису займає певний час, то виконання всього скрипта може банально впертися в ліміт max_execution_time, а використання set_time_limit(0) як потенційного лайфхаку швидше за все банально приведе до HTTP timeout - тому розділяйте свою БД на кілька CSV файлів за якимись ознаками, типу місто, вулиця, тег, IP-мережа, etc