Что делать с документами на старых базах данных?

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

если и сделаю миграцию, я займусь ей в последнюю очередь, но боюсь, все равно не успею

Есть ли какой-нибудь способ надежно сохранить остатки средств в новой базе, чтобы никто не мог их изменить?

есть - реальные актуальные данные вдампить непосредственно перед вводом в эксплуатацию, а до того пусть тестовые щупают.

Хотелось бы узнать, что думают опытные разработчики

Ты как бы не по адресу обращаешься. Огласи варианты заказчику, путь он и думает, что ему лучше.

В идеале данные должны быть мигрированы, но так как я пока один, у меня нет на это времени

А в чём проблема, там дохрелион таблиц? На первый взгляд сдампить SQL и всосать на новый сервер выглядит как задача на пару дней максимум.

У меня была похожая ситуация. Пришли к варианту 3 - постепенно (при первой работе с объектом в новой системе) делался запрос данных в старую, а оператор сверялся с данными и, при необходимости, вносил корректировки (т.к. новая система стала более детализированная в вопросах работы со средствами).

Таким образом, хоть и немного сложно для операторов, старые сведения отлично влились в требования новой системы.

Пиши четвертую версию, несовместимую с предыдущими, все равно скоро увольняться.

должны быть мигрированы, но так как я пока один, у меня нет на это времени

Ну т.е. время отлаживаться на 3-х (!) старых базах (с разными ведь схемами?) есть, а на миграцию нету?

Ну универсальный совет тут оставить старые данные в старых системах, в новой работать только с новыми, запрогать защиту от пересечений, а потом (т.е. никогда) перенести старые данные в новую систему ну или новые вместе с старыми в ещё более новую систему.

Если номера фактур или номера договоров привязаны к первичным ключам таблиц – лучше оставить как есть, так как изменять эти номера нельзя.

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

У меня задача разработать на одном предприятии новую версию(вариант) ПО, которая является одной маленькой частью большой системы

То есть по итогу будет 4 версии ПО на предприятии.

А миграция = 1-tool-to-rule-them-all

И года выяснится что у «новой программы» есть фатальный недостаток(а это выяснится) будет ТС бегать с горящей жопой, или просто скроется

А потому лучшее что можно сделать - разделение ответственности ИС: и все что новая ИС не пишет, пусть собирает из трех других ИС по ночам

Тем более ТС говорит что он один, а значит там не будет ни QA, ни прочих третьих глаз

да, о таком сценарии я тоже подумал, но решил, что тс, как человек на месте, лучше знает местные реалии разработки и эксплуатации и какую задачу ему ставил заказчик. Я прочитал из оп поста, что задача заменить(возможно поэтапно) 3 имеющихся приложения одним новым, возможно ошибся

Разбирайся, насколько отличается структура данных в этих 3 старых базах от твоей текущей. То, что используются разные СУБД — не очень большая проблема, преобразовать из одного формата в другой не должно быть особенно сложно (тем более, что наверняка есть импорт/экспорт в какой-нибудь CSV), но только если структура данных не сильно отличается. Плюс, как уже сказали, может быть проблема с ключами. Она тоже решается. Например, добавляешь поле oldId, куда помещаешь ключ из старой базы, а основной id будет уже автоинкрементальным в рамках твоей новой базы. Но если структура отличается сильно, при миграции потребуются какие-то нетривиальные преобразования, тогда да, это может стать проблемой, тогда нужно думать в сторону какой-то интеграции со старой базой, которая останется как есть