Алексей Киселев

Безусловно, вам нужны будут:
- Полные исходники, включая все зависимости, а также файлы проектов. В идеале репозиторий целиком.
- Исходные макеты для дизайна, а также готовые (напр., нарезанные) картинки во всех необходимых разрешениях, если таковые используются в приложениях.
- Если они использовали какой-нибудь облачный бэкенд, - все доступы к аккаунтам бэкенда.
- Если они использовали свой частный бэкенд, - необходим перенос их бэкенда на ваш сервер. После этого удостовериться, что все работает, как прежде (для людей технически неподкованных задача нелегкая, хотя все зависит от реализации).
- Если они использовали какие-то библиотеки третьих лиц или обращаются в коде к серверам третьих лиц, которые подразумевают использование ключей (напр., авторизация в соц. сетях, рекламных сетях, сервисы Гугла и т.д и т.п.), необходимо забрать все ключи и доступы к админкам этих ресурсов.
- В случае с Apple App Store, необходимо совершить миграцию приложения на ваш аккаунт (https://developer.apple.com/library/ios/documentat...). Естественно, этот эккаунт нужно заранее создать и разобраться, как что настраивать, какие сертификаты и для чего генерировать. Все последующие апдейты уже надо будет подписывать вашими новыми сертификатами. По Андроиду, думаю, нужно совершить похожие действия.

P.S.: Важно учесть, что нельзя менять ключи на новые и отключать старые сервера бекэндов до того, как не выпустите апдейт клиентских приложений с новыми ключами и URL-ами, иначе вся сетевая работа приложениях остановится.

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

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

Ну и если разработка нативная, за андроид могу сказать, что главное чтобы был у вас сертификат которым приложение подписывалось при сборке, для публикации в стор + данные по этому сертификату(алиасы, пароли). Ну и собственно java(если используется NDK c/c++) код с ресурсами типа картинок, строк и прочего.

Никак. И вообще, опыт с Oracle vs Google никого ничему не учит. Вообще, код должен быть open source. Зарабатывает не код, зарабатывают бизнес-процессы, то есть продажи.

Но вообще, чисто теоретически, если код СТОЯЛ на балансе (так можно, хоть так и не удобно... очень не удобно), то можно доказать кражу, хоть и невероятно сложно, особенно в этой стране. Если изменены все названия функций и переменных, но сохранена логика, то чисто теоретически, можно доказать кражу с изменением структуры программы с помощью технических средств (перед этим придётся доказать возможность такого изменения именно с помощью технических средств), но гемороя в тысячи раз больше. Но если были изменения в логике, то это уже не вариант. Наконец, если вор идиот и украв код, залил его на svn или git, а потом меня, то чисто теоретически, можно попытаться завести дело и изъять технику до чистки улик.

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