Rewrite attractive লাগে, কারণ new code-এর visible history নেই।

Old application-এ inconsistent pattern, dependency, workaround এবং কেউ মনে রাখেন না এমন decision থাকে। Blank repository clean মনে হয়।

কিন্তু old system-এর valuable কিছু আছে: বছরের পর বছর discover হওয়া behavior।

User এমন edge case-এর ওপর নির্ভর করেন যা documentation-এ নেই। Operation নির্ভর করে export, URL, timing ও error behavior-এর ওপর। একবারে সব replace করলে technical debt সরিয়ে product debt তৈরি হতে পারে।

Application recoverable হলে আমি controlled modernization prefer করি।

আগে ঠিক করুন modernization উপযুক্ত কি না

Incremental work সবসময় answer নয়।

Replacement justified হতে পারে যখন:

• platform unsupported এবং secure করা যায় না;
• architecture required business model block করে;
• data model domain safely represent করতে পারে না;
• product retire বা fundamentally redefine হচ্ছে;
• reasonable cost-এ deployment ও testing reliable করা যায় না;
• licensing বা provider constraint migration বাধ্যতামূলক করে।

তবুও new component library দিয়ে শুরু করি না। Behavior, data, user এবং transition risk দিয়ে শুরু করি।

Broader decision-এর জন্য দেখুন legacy web app fix নাকি rewrite।

Baseline তৈরি

Architecture বদলানোর আগে record করি:

• critical user journey;
• active route ও API inventory;
• authentication ও permission model;
• data source ও mutation;
• provider integration;
• deployment path;
• production error;
• browser ও device requirement;
• performance evidence;
• test coverage;
• support pain;
• known security risk।

প্রতিটি line document করা লক্ষ্য নয়। Modernization কোন behavior preserve বা intentionally change করবে তা চিহ্নিত করাই লক্ষ্য।

Development loop stabilize

Change safe কি না team বুঝতে না পারলে modernization dangerous হয়।

আমি priority দিই:

• reproducible local setup;
• deterministic dependency install;
• environment validation;
• lint ও type check;
• critical behavior-এর focused test;
• predictable deployment process;
• error reporting;
• rollback path।

এই control পরের refactor-এর feedback দেয়।

Current product-এ test না থাকলে complete coverage-এর জন্য অপেক্ষা করি না। Riskiest path বদলানোর আগে characterization test যোগ করি।

Existing app-এর ভেতর boundary আঁকুন

Legacy React app-এ প্রায়ই একসঙ্গে মেশে:

• API call;
• view rendering;
• form state;
• business rule;
• persistence assumption;
• analytics;
• authorization decision।

Highest-change বা highest-risk concern আগে আলাদা করি।

উদাহরণ:

• provider call adapter-এর পেছনে নেওয়া;
• domain decision pure function-এ নেওয়া;
• API boundary-তে runtime validation centralize;
• typed response model;
• authentication state isolate;
• duplicated formatting এক utility-তে নেওয়া;
• data fetching consistent query layer-এর পেছনে নেওয়া।

Folder perfection লক্ষ্য নয়। পরের change যেন কম unrelated concern touch করে সেটিই লক্ষ্য।

Route বা feature slice ধরে replace

Practical modernization unit হলো user capability, random file group নয়।

একটি slice-এ থাকতে পারে:

1. route;
2. data query;
3. permission check;
4. form behavior;
5. loading ও error state;
6. test;
7. analytics;
8. release verification।

Rest of app operational রেখেই slice newer pattern-এ যেতে পারে।

এই approach comparison, rollback এবং gradual learning support করে।

Server ও client responsibility deliberate

Modern React framework-এ new API convenient বলে boundary move করা সহজ।

আমি data ও interaction অনুযায়ী সিদ্ধান্ত নিই:

• secret ও privileged provider access server-এ;
• server entry point-এ authorization enforce;
• static বা data-heavy rendering server-side হতে পারে;
• interactive state focused client boundary-তে;
• browser শুধু প্রয়োজনীয় data পায়;
• mutation invalidation explicit।

Next.js version-এর reasoning পড়ুন server ও client component boundary-তে।

URL ও data contract preserve

Modernization casually break করবে না:

• bookmarked route;
• search-indexed URL;
• external link;
• API consumer;
• stored identifier;
• export format;
• analytics continuity;
• locale behavior।

Public URL বদলালে redirect ব্যবহার করুন। Caller একসঙ্গে move করতে না পারলে API version বা adapter দিন। Migration restart-safe ও observable করুন।

Transition-এর সময় compatibility একটি product feature।

কারণসহ dependency upgrade

“সব update করুন” unrelated risk একসঙ্গে করে।

আমি purpose অনুযায়ী group করি:

• security বা support deadline;
• framework migration prerequisite;
• runtime compatibility;
• build reliability;
• abandoned dependency removal;
• feature-specific need।

প্রতিটি group-এর জন্য version-matched documentation পড়ি, breaking change identify করি, focused check চালাই এবং rollback point রাখি।

এতে failure diagnose করা যায়।

Redesign ছাড়া interface improve

Modernization familiar UI preserve করে implementation quality বাড়াতে পারে।

Useful work:

• semantic HTML;
• keyboard behavior;
• focus visibility;
• accurate loading ও error state;
• form label;
• reduced-motion handling;
• responsive overflow fix;
• image ও font efficiency;
• component consistency।

নতুন aesthetic দিয়ে user-কে surprise করা লক্ষ্য নয়। Existing experience-কে reliable ও accessible করা লক্ষ্য।

প্রতিটি slice measure

Change অনুযায়ী evidence define করি:

• error reduction;
• faster task completion;
• smaller client JavaScript;
• improved route response;
• fewer support case;
• stable conversion;
• reduced deployment failure;
• vulnerable dependency removal;
• critical path test coverage।

সব slice সব metric improve করবে না। Implementation-এর আগে expected result বলা উচিত।

Old path deliberately retire

Temporary compatibility code permanent হয়ে যাওয়ার অভ্যাস আছে।

প্রতিটি old path-এর জন্য চাই:

• owner;
• usage evidence;
• removal condition;
• target date বা review point;
• safe fallback;
• affected user communication।

Traffic, caller এবং operational dependency বোঝার পরই remove করুন।

Modernization roadmap

Practical sequence:

1. inventory ও risk map;
2. reproducible setup;
3. observability ও critical regression test;
4. boundary extraction;
5. একটি representative vertical slice;
6. measure ও adjust;
7. business priority ধরে repeat;
8. unused path retire;
9. handover ও maintenance documentation update।

Day one-এ empty repository তৈরির চেয়ে এটি slow মনে হয়। Big-bang rewrite-এর পরে প্রতিটি production requirement আবার discover করার চেয়ে প্রায়ই faster।

আপনার React application modernize করা দরকার হলে current stack, সবচেয়ে painful workflow এবং change বাধ্য করছে এমন constraint পাঠান।