3) Он выгружает все поля, как есть, т.к если в объекте есть ключевое поле, по которому можно найти, то по нему и делать поиск. Неудобно, но жить можно. Еще как вариант, это сделать архивный сервер, а с боевого сервера удалить все объекты которые можно отнести к архивным данным.
Получиться, если нужны архивные данные, то специалист меняет только имя сервера подключения.
4) А как мы определим, что данные являются устаревшими? По дате создания? А если фтп меняли с диска на диск? Или, допустим, есть объект с номером 1234 создан в 2008 году. А в 2011 году этот объект добавили файл, выходит, что у данного объекта 1 файл является новым, а объект относиться к архиву.
Читабельны будут, вопрос в другом, как удалить только те объекты, которые действительно нужно удалить, а если требуется сохранение заявок, скажем, придет проверка и скажет, а на основании чего Иванову предоставили доступ? Поиском по базе можно будет найти в два счета, а если элемент удален, то придется мало того что долго и упорно ковырять xml еще придется искать все вложения которые были в данном обращении…
5) FTP меняли на более ранней стадии, чем 23 пак, поэтому можно использовать и боевой, только очень осторожно. Я бы поднял новый FTP и не подключал его к боевому серверу, на то это и тестовый стенд. И без FTP стенд работать будет, все зависит от того, что на нем тестировать.
6) Тут не все так просто с SP, если в систему внедрялись сторонние обновления, в хостфикс, или еще как, то желательно на тестовом стенде произвести обновление.. и посмотреть на кол. Ошибок, если они будут, и методы их решения. Посмотреть, как делается обновление локальных клиентов удаленно, настроить все на тестовом стенде, оттестировать все пару раз, а уж потом и делать обновление. При этом уведомить всех специалистов, что их ожидает при запуске системы. Ну и соответственно указать им какие новшества их ожидают.