Конечно нет. Гораздо удобнее, чем фигачить скрипт

Комментарии жирным внутри.

Самая главная беда - интеграция с панелями. Особенно если учесть, что некоторые из них полностью или частично закрыты. Ещё надо помнить, что бекап-переносы в рамках одних и тех же панелей, разработанных разработчиками (извините за тавтологию) и то часто вызывают проблемы.

Доброе утро, коллеги


> ...Гораздо удобнее, чем фигачить скрипт


Конечно, программа, где клиент выбирал бы из одного выпадающего меню старого хостера, тариф,
из другого меню - нового хостера (и тариф из открывшегося окна), вводил бы пароли, нажимал
кнопку [transfer], выбирал бы чекбокс [also change NS-servers] и... через мгновение его сайт
переносился на новое место - идея бесподобна. И, вероятно, мы со временем к этому придем -
лично я не вижу ничего фатально невозможного. Но пока стоимость реализации такой идеи,
к сожалению, ощутимо высока.

Скрипт (набор скриптов), во-первых, не должен быть сложным - у него две задачи: проверить
совместимость площадок (по заранее согласованным критериям) и запаковать файлы/базы/имена ящиков
и, возможно, файл с текстовой служебной информацией в соответствии с согласованным форматом
(структурой). Во-вторых, скрипты каждый хостер пишет сам, афишировать свою структуру и не требуется.
Нужно только договориться о стандартах упаковки, так сказать, о техническом протоколе - о структуре
самого архива. Но не более того.

Все это не слишком сложно, но для клиента - весьма ощутимая поддержка. Бережное отношение
и техническая помощь.

Одно другому, мне кажется, не мешает. Как минимум - можно договориться о едином формате такой сопроводительной записки, и в это время работать над максимумом - полной (или максимальной) автоматизацией.

Повторюсь, Пётр.

Допустим у первого хостера на сервере включено в PHP:
-"модуль 1"
-"модуль 2"
-"модуль 3"

Клиент использует:
-"модуль 1"
-"модуль 3"

Как провайдеру делать такую сопроводительную записку?

Он может загнать туда все свои настройки, но тогда, если у нового хостера отсутствует "модуль 2" делается вывод, что клиента туда переносить нельзя. А клиент это на деле не использует...

Что реально использует клиент (в теории) может знать только клиент. На деле он этого часто не знает.

Как Вы понимаете, модулей и настроек далеко не три...
Вот, например: http://ursu.su/php.php
И попробуйте угадать, что там используется, что нет...
К сожалению, я не знаю как эту задачу решать.

Юрий, извините, может не совсем приятную вещь скажу, может и не к месту, т.к. критика в любом деле всегда полезнее, чем одобрительное кивание. Но критика должна быть конструктивной, отвергая чужую идею Вы должны тут же предлагать свою.

Дело в том, что услугами хостинга от Swordin я пользовался еще чуть ли не с конца прошлого века . И с тех пор постоянно с ним общаюсь. Поэтому простыми словами о том, что "это невозможно сделать только потому, что я не представляю как" меня не убедить в том, что Swordin предлагает глупость не подумав и не взвесив свое предложение.

Конструктивной критике я только рад

Что касается предложения уважаемого коллеги из РБК, то тут далеко ходить не надо. Вспомните Highway. Тот конечно вообще автоматизации не имел и время другое было, но тем не менее с переносами там тоже было очень и очень весело...

Что касается переходов от общего к частному, то я привёл выше конкретную проблему с конфигурациями PHP. Решения которой лично я не вижу. Возможно Вы или Swordin или другие участники темы смогут предложить варианты, но тем не менее проблема с PHP - капля в море. Давайте попробуем сейчас хотя бы её решить.

Я тоже не знаю. Давайте все вместе думать.

И для начала поинтересуемся у технарей насколько важна им конкретизированная спецификация окружающей среды конретного проекта. Или для того, чтобы понять будет он работать у них или не будет, достаточно общей развернутой спецификации с прежнего места расположения проекта.

Распарсить клиентские скрипты и сделать сопоставления используемых функций с модулями. Нашли mysql_connect() - проект использует MySQL. И т.д. Работы не просто много, а очень много.

А если зазендено-заионкублено? Слишком сложно.

Юрий, мне кажется, задачу - сделать вывод о возможности переноса - скрипту ставить
не нужно. Пока, во всяком случае. Цель, о которой говорит Петр - облегчить жизнь клиенту (да и нам,
кстати) при переносе сайта. Для этого достаточно автоматизировать процесс упаковки/распаковки
в заранее согласованном формате и сопроводить архив технической запиской
в заранее согласованном виде. Определять возможность переноса будут специалисты -
используя вот такой вот вспомогательный инструмент.

Давайте начнем с малого. В совокупности с организационными декларациями (о помощи клиенту) -
это уже принципиально выделит компании, готовые относиться к пользователям чуть лучше.

Поясните, пожалуйста, что именно Вы подразумеваете под такой запиской?

Вот это нужно обсуждать специалистам, занимающимся переносом и настройкой. Нужно выбрать
оптимальную глубину и необходимый минимум полезной детализации. Вероятно важными могут оказаться
версии ключевых продуктов: apache, mysql, php... Описывать в первую очередь нужно то, что нельзя
(трудоемко) изменить.

Давайте спросим у системных администраторов / вебмастеров - что бы им хотелось увидеть в этом
файле, чтобы не обращаться к "старому" хостинг-провайдеру за вопросами, а сразу иметь представление
о прежней площадке аккаунта?

В конце концов, эта сопроводительная записка - всего лишь вспомогательный источник технических
сведений, которые могут оказаться полезными на этапе настройки распакованного сайта (под сайтом
я сейчас понимаю всю совокупность объектов хостинг-аккаунта). Конечно, формализация структуры
этой записки - важная часть общего "протокола обмена клиентами" но не следует преувеличивать
её значение. Как и любой другой протокол - этот так же будет развиваться по мере его использования.
Дорогу осилит идущий!

Режим работы PHP (FastCGI, ...)
SafeMode
register_globals
и т.д.
Полный путь к сайту на сервере (например для SMF он имеет значение)
Разрешенные директивы htaccess

продолжайте...