Для упрощения использования любой новой технологии (и для описанных выше конвертаций ASP проекта в проект JSP/PHP) жизненно необходимо абстрагировать системные средства ASP в библиотеку общего пользования. Эту библиотеку можно специально приспособить под конкретный проект, для значительного упрощения ее применения. Рассмотрим типичных кандидатов на помещение в общую, объектно-ориентированную, библиотеку.

    Config - это объект, который хранит все настройки, общие для сайта в целом. Реально, они будут записываться при старте сайта в ASP коллекцию Application(), например из конфигурационного XML или INI-файла или просто из global.asa.  Но весь остальной ASP-код работает с конфигурационными параметрами исключительно через этот объект и к способу хранения/чтения этих параметров никак не привязан. Параметры конфигурации могут быть представлены, в объекте Config, как атрибуты объекта и/или как методы getStr("Section","Entry","Default"), getInt(...),  getBool(...), и т.д. 

    ConfigUser - этот объект хранит переменные текущей сессии пользователя. Абстрагируя переменные сессии в этот объект, мы получаем независимость от способа хранения переменных сессии. Мы можем как угодно менять и комбинировать способы хранения этих переменных: коллекция Session(), Cookies, Database, поля HTML формы - что угодно. При этом основной код будет оставаться неизменным. Доступ к переменным можно организовать аналогично объекту Config, но уже с возможностью модификации этих переменных - getStr(...)/setStr(...), и т.д.

    Тут возникает весьма неоднозначный вопрос - об именовании объектов. Как в ASP, так и в сервлетах/JSP общую конфигурацию рекомендуется  записывать в коллекцию Application (application), а пользовательскую - в Session (session). Проблема в том, что концепции коллекций Application и Session подразумевают то, что туда можно записать все, что угодно и время жизни этих коллекций ограничено. Они универсальны, и не приспособлены специально для хранения конфигураций. 
    Поэтому назвать наши конфигурационные объекты надо как-то по-другому (не application и session). Например: ConfigApp/ConfigUser, AppProperties/UserProperties, GlobalProperties/SessionProperties и т.п. Еще один фактор - это сокращения в названиях. Это не очень хороший стиль, поскольку многие сокращения могут оказаться непрозрачны для некоторых разработчиков. 
    Вопрос о поиске хороших наименований является очень тяжелым и субъективным. Автор будет весьма признателен, если кто-то предложит удачные короткие названия для двух вышеприведенных объектов, которые встречаются почти во всех проектах.

    ObjectFactory - если задуматься о будущем, то запись Server.CreateObject(...) в основном ASP коде покажется весьма ограничивающим фактором. Если понадобится использовать J2EE CAS COM Bridge (мост от Sun для использования EJB и обычных Java-классов через COM),  то процесс создание объекта уже будет отличатся, и запишется так (JScript):

_factory = Server.CreateObject("J2EECAS.JavaClassLoaderFactory");
_classloader = _factory.CreateClassLoader();
_class = _classloader.FindClass("java.lang.String");
objJavaStr = _class.New();

И основной ASP код придется переписывать. Для мостов CORBA придется использовать другую запись. Нет, конечно, может быть не все так плохо, и возможно для данного конкретного проекта никогда не понадобится связь ни с EJB, ни с CORBA, ни что-нибудь еще (пострашнее :) ). Но кто знает...  
    Если вы все же решились абстрагировать и эту сторону проектной реальности, то ObjectFactory, минимально должен предоставлять 2 метода - создание и удаление объекта. Не важно что обычно удалением объектов занимался сборщик мусора. Пусть даже наш метод удаления объекта на самом деле ничего не делает - это не важно. Пусть он будет, и пусть он вызывается когда нужно - будущее нас рассудит. 
    У каждого объекта 2-nd tier должен быть псевдоним для его идентификации при обращении к ObjectFactory. Например в основном коде будет запись ObjectFactory.CreateObject("MailSender"); И только ObjectFactory на самом деле будт знать что это COM объект с AppId "com.sa.soft.utils.SendMail005". 
    Параллельно ObjectFactory можно нагрузить мелкими функциями  - контролем всяческих пулов и кэшей, проверкой валидности объекта, etc. 
    И, чтобы уж совсем по-модному, доступ к вышеописанным объектам должен осуществляться через единственный объект-ядро:

    Core - этот объект должен присутствовать во всех ASP страницах  основного кода в единственном экземпляре (синглетонами также должны быть объекты Config, ConfigUser и ObjectFactory. а вот DB-объекты - необязательно).  Главная задача объекта Core - создавать и возвращать все описанные выше объекты написанной вами библиотеки, гордо именуемой Project ASP API. 
    Например, Core.getConfigApp() создаст объект ConfigApp и вернет на него ссылку. Повторный вызов не будет создавать объект повторно, а вернет ту же ссылку (чтобы гарантировать, что ConfigApp останется синглетоном). Помимо того, что основной ASP-код станет более понятным, мы получим весьма полезный эффект. Core может запоминать ссылки на все созданные им объекты. И вызвав в конце ASP-страницы метод, например, Core.close(), мы получим гарантированное закрытие всех объектов, даже если мы забыли закрыть их в основном коде. Для объектов работы с базой данных это особенно критично.

    Конечно, стандартным должен быть и объект для работы с источником данных, но о нем позднее.