Скороход,

Подозреваю, что у "самых больших дядек" сделано как-то так . Если же масштабы поменьше и тестовое приложение развернуто на той же базе, что и рабочее, то можно поступать следующим образом:
Ставим рабочему приложению alias, к примеру, f100.

Все пользователи заходят в приложение не по application_id, а по alias (f100).

Копируем тестовое приложение (не экспорт/импорт, в home application есть ссылка copy application, которая создает в текущем воркспейсе копию).

В рабочем приложении ставим статут unavaliable with redirect и указываем url redirect как адрес скопированного приложения. Меняем алиас f100 на f100_old.

В скопированном приложении ставим алиас f100 и оно становится рабочим.
При таком подходе всегда под рукой остаются прошлые стабильные версии, меняя только alias можно быстро между ними переключаться. Правда, всех пользователей выкинет из сессии при накатке таким образом.

Скороход,

На локальном диске лежит около сотни sql-файлов с экспортированными приложениями. Часть из них экспортирована вручную, часть автоматически . В самом воркспейсе единовременно находятся 3-5 приложений: рабочее, тестовое, парочка старых. Старые удаляются по мере потери актуальности. Все хп для апекса находятся в пакете, которой при изменении выгружается в отдельный sql-файл (в том числе для проводки на других базах). Так же хранятся все версии отдельной js-библиотеки.
Минус такого подхода - все приходится делать руками. Хотя, при желании, все это можно захардкодить на системных таблицах самого апекса.

Скороход,

Конкретно в моем случае тестовые данные легко отделяются от рабочих логикой самого приложения, поэтому особого смысла в поддержании двух разных схем/баз нет.