با جایگزین‌کردن تدریجی بخشهای خاصی از توابع و قسمتهای مهم و عملیاتی برنامه قدیمی با برنامه‌ها و سرویس‌‌های جدید، یک سیستم قدیمی را به‌تدریج به سیستم جدیدتر تبدیل کنید. همان‌طور که ویژگیهای سیستم قدیمی جایگزین می‌شوند، سیستم جدید در نهایت جایگزین همه ویژگیهای سیستم قدیمی می‌شود، سیستم قدیمی را تضعیف می‌کند و به شما امکان می‌دهد آن را از کار بیندازید.
با افزایش سن سیستم ها، ابزارهای توسعه، فناوری میزبانی و حتی معماری سیستمی که بر اساس آنها ساخته شده‌اند، می‌توانند به طور فزاینده‌ای منسوخ شوند. با اضافه‌شدن ویژگی‌ها و عملکردهای جدید، پیچیدگی این برنامه‌ها می‌تواند به طور چشمگیری افزایش یابد و نگهداری یا افزودن ویژگیهای جدید به آنها سخت‌تر شود.
جایگزینی کامل یک سیستم پیچیده می‌تواند کار بزرگی باشد. اغلب، شما نیاز به انتقال تدریجی به یک سیستم جدید دارید، درحالی‌که سیستم قدیمی را برای کنترل ویژگی‌‌هایی که هنوز منتقل نشده‌اند حفظ می‌کنید. بااین‌حال، اجرای دو نسخه جداگانه از یک برنامه به این معنی است که مشتریان باید بدانند ویژگیهای خاص در کجا قرار دارند. هر بار که یک ویژگی یا سرویس منتقل می‌شود، مشتریان باید برای اشاره به مکان جدید باید به‌روزرسانی شوند.
به طور تدریجی بخشهای خاصی از توابع و قسمتهای عملیاتی مهم را با برنامه‌ها و سرویس‌‌های جدید جایگزین کنید. یک نما یا façade ایجاد کنید که request هایی را که به سیستم قدیمی backend می‌روند را رهگیری کند. façade این درخواست‌ها را یا به برنامه قدیمی یا سرویس‌‌های جدید هدایت(route) می‌کند. ویژگیهای موجود را می‌توان به‌تدریج به سیستم جدید منتقل کرد و مصرف‌کنندگان می‌توانند به استفاده از همان رابط یا interface ادامه دهند، غافل از اینکه متوجه بشوند که هرگونه تغییر یا migrate صورت‌گرفته است.
این الگو کمک می‌کند تا خطر migrate به حداقل برسد و تلاش برای توسعه نرم‌افزار در طول زمان پخش شود. ازآنجایی‌که façade کاربران را به طور ایمن به برنامه صحیح هدایت می‌کند، می‌توانید با هر سرعتی که دوست دارید عملکردی را به سیستم جدید اضافه کنید و درعین‌حال اطمینان حاصل کنید که برنامه قدیمی به کار خود ادامه می‌دهد. باگذشت زمان، با انتقال ویژگی‌ها به سیستم جدید، سیستم قدیمی در نهایت 'خفه(strangled)' می‌شود و دیگر ضروری نیست. پس از تکمیل این فرایند، سیستم قدیمی می‌تواند با خیال راحت بازنشسته شود.
نحوه مدیریت سرویس‌ها و ذخیره‌‌های داده‌ای که به طور بالقوه توسط سیستمهای جدید و قدیمی استفاده می‌شوند را در نظر بگیرید. مطمئن شوید که هر دو می‌توانند در کنار هم به این منابع دسترسی داشته باشند.
از این الگو هنگام انتقال تدریجی یک برنامه back-end به یک معماری جدید استفاده کنید.
این الگو ممکن است مناسب نباشد:
* زمانی که درخواست‌ها به سیستم back-end قابل‌رهگیری نباشد.
* برای سیستمهای کوچک‌تر که پیچیدگی تعویض به سیستم جدید بسیار کم است.