Быстро?Это то, что хочет каждый менеджер, но я сомневаюсь в этом.
У вас есть принципиально разные модели пользовательского интерфейса и разные языки программирования.Если эти приложения не являются небольшими, маловероятно, что они смогут преобразовать их вручную в любой короткий промежуток времени (или даже самостоятельно, поскольку, как представляется, ОП подразумевает «я намерен»).
Gartner Group проанализировала ручные миграции и предлагает, если все "похоже", фактический коэффициент конверсии составляет ~ ~ 150 строк / день, что возможно, потому что вы переводите более или менее непосредственно из рабочего отлаженного приложения.,(Насколько велико приложение в SLOC?) Итак, если у вас 75 000 строк кода, вы смотрите на минимум 500 человеко-дней.Вы могли бы доказать, что Delphi как языки программирования и C # похожи.Вы не можете обоснованно обосновать это для пользовательского интерфейса Delphi и Silverlight, поэтому эта оценка является нижней границей.
Есть такие, которые говорят: «просто выбросьте и перекодируйте его с нуля».Если ваша производительность не превышает 150 отлаженных строк кода в день [классические тексты по разработке программного обеспечения скажут вам, что он намного меньше этого], это займет у вас еще больше времени.Обычно это дает сбой, потому что вы в конечном итоге забываете о том, какие функции существуют в текущей программе, и заново обнаруживаете их на поздних стадиях разработки или, что еще хуже, после попытки повторного внедрения.Обычно происходит то, что старое приложение продолжает развиваться, пока строится новое (помните, что вы находитесь на расстоянии 500 человеко-дней от нового минимума!), И новое должно сыграть в догонялки с этими изменениями.Если приложение имеет какой-либо серьезный масштаб (например, миллион строк), это часто предотвращает возможность обслуживания нового приложения.Еще один способ думать об этом: «сколько времени потребовалось для создания исходного приложения?» И «почему создание замены должно быть намного проще?».YMMV, если вы можете творить чудеса.
Мое очень предвзятое мнение (я создаю инструменты перевода на язык), что один из наиболее практичных способов сделать это - автоматический перевод.Это тоже имеет свои издержки;они не являются готовыми предметами, независимо от того, что кто-то говорит вам.Вы настроили переводчик, и это также отнимает много энергии, но эта энергия пропорциональна размеру используемых библиотек language и (UI) , а неразмер приложения, поэтому он становится намного более эффективным, поскольку программа становится большой.Это все еще порядка сотен человеко-дней, чтобы кодировать и тестировать только для части перевода языка.Разница в том, что после настройки вы можете применить его к существующему приложению любого размера, в каком бы состоянии оно ни находилось. Есть больше сложностей, чем это, но этот подход преодолевает проблему «не догнать» ручных преобразований.и "не хватает кодировщиков для его ручного перевода".
Подробнее см. в моем ответе о том, как переводить между языками .
Если вашПриложение относительно небольшое, ИМХО нет хороших ответов.Ручной перевод или перекодировка, вероятно, ваш единственный (безобразный) выбор.