“Rewrite করা উচিত”—software-এর সবচেয়ে expensive sentence-এর একটি।

কখনো ঠিক।

অনেক সময় না-মাপা pain-এর reaction।

Existing application change করা slow। Bug ফেরে। Release trust করা যায় না। Old system বোঝার চেয়ে new framework clean লাগে।

Feeling সত্যি।

এখনো migration plan না।

Pain-এর নাম দিন

Complaint-কে evidence-এ ভাঙি:

• কোন change বেশি সময় নেয়?
• কোন defect repeat?
• কোন module incident করে?
• কোন dependency unsupported?
• কোথায় data integrity risk?
• deployment কী block করে?
• team কী test করতে পারে না?
• কোন business capability move করতে পারছে না?

“Code messy” symptom।

Decision-এর জন্য failure map দরকার।

Rewrite domain complexity সরায় না

Old code-এ বছরের decision থাকে।

কিছু খারাপ।

কিছু খারাপ দেখায়, কারণ business rule সত্যিই complex।

এই পার্থক্য না বুঝলে new team production bug দিয়ে rule আবার discover করে।

খুঁজি:

• hidden status transition;
• permission exception;
• migration history;
• billing edge case;
• import/export contract;
• business-এর quietly dependent report;
• manual recovery procedure।

Document না থাকলেও এগুলো requirement।

ছয় dimension

১. Business continuity

New system catch up করা পর্যন্ত product থামতে পারে?

২. Boundary quality

এক module stable contract-এর পেছনে isolate করা যায়, নাকি সব change global?

৩. Testability

Change-এর আগে current behavior capture করা যায়?

৪. Data risk

Migration, reconciliation, rollback আর dual operation কত কঠিন?

৫. Platform viability

Runtime আর dependency stabilize করার মতো supported?

৬. Team ownership

Rewrite-এর পরে current team target architecture maintain করতে পারবে?

এক number না।

Dimension শুরু কোথায় হবে—দেখায়।

Choose করার আগে stabilize

Short stabilization phase:

1. costly failure reproduce;
2. critical path observability;
3. representative test;
4. data আর integration boundary document;
5. এক operational danger remove;
6. change safe হয়েছে কি না measure।

Rewrite হলেও কাজ নষ্ট না।

Test, contract আর failure map migration asset।

দুই না, তিন strategy

শুধু “fix” বা “rewrite” না।

Repair in place

Platform viable, pain concentrated।

Incremental replacement

এক bounded capability new contract-এর পেছনে, rest চলবে।

Full rewrite

Core assumption, platform support, data model বা operational boundary incremental-এর চেয়ে replacement safe করলে।

Full rewrite-এর migration আর rollback plan দরকার।

“New one launch” rollback plan না।

Strangler boundary define

Incremental modernization-এর first capability:

• clear input/output;
• measurable behavior;
• limited data ownership;
• routing বা adapter seam;
• independent verification;
• ফিরে যাওয়ার পথ।

যেমন:

• authentication;
• notification;
• reporting;
• public frontend;
• এক workflow;
• external integration।

Best boundary matter করার মতো valuable, শেখার মতো contained।

Rewrite theatre

Red flag:

• failure map-এর আগে framework;
• business rule inventory নেই;
• migration rehearsal নেই;
• reconciliation নেই;
• parallel-run decision নেই;
• screen count থেকে deadline;
• owner ছাড়া “clean architecture”;
• contract ছাড়া old-new independent change।

Rewrite একসাথে দুই legacy system বানাতে পারে।

আমার rule

Evidence যদি বলে foundation safe change ঠেকায় এবং incremental boundary reasonable cost-এ risk কমাতে পারে না—rewrite।

Product value intact আর pain isolate করা যায়—repair।

Continuity জরুরি আর usable seam আছে—incremental replace।

Goal new code না।

Goal safer business change।

ছোট boundary-এর জন্য পড়ুন big-bang ছাড়া React modernization। Release protection-এর জন্য production code-review checklist।

Team rewrite নিয়ে debate করলে preferred framework না, failure map পাঠান।