Рискът не е равномерен във времето
Стара система обикновено работи, докато не спре. Проблемът е, че моментът е непредвидим, а без документация и без автор възстановяването се измерва в дни, не в часове.
Системата е писана преди години. Човекът, който я е правил, отдавна не е насреща. Работи — но всяка промяна се отлага, защото никой не знае какво ще счупи.
Това не е техническа авария. Това е риск, който расте бавно и се проявява в най-лошия възможен момент.
Ако разпознаваш повече от два от тези, рискът вече е реален, независимо че системата работи.
Разходът не е в месечна такса — той е в риск, който расте, и в заобикаляния, които стават постоянни.
Стара система обикновено работи, докато не спре. Проблемът е, че моментът е непредвидим, а без документация и без автор възстановяването се измерва в дни, не в часове.
Когато системата не може да се промени, промяната се прави отстрани — в таблица, на ръка, чрез втори процес. Тези заобикаляния се натрупват и стават постоянен разход.
Софтуер на неподдържана версия не получава поправки за уязвимости. За система с лични данни на клиенти това е и регулаторен риск, не само технически.
Стари системи рядко имат API. Това означава, че всяка нова програма, която въведеш, ще живее отделно — и ще ти трябва човек, който да пренася данни между двете.
Пренаписване наведнъж е най-рисковият вариант — затова започваме с одит, а не с оферта.
Установяваме какво реално прави системата, на какво стъпва, има ли изходен код и къде живеят данните. Без този одит всяка оценка на срок и цена е предположение.
Не всичко трябва да се пренаписва. Понякога стабилизиране и добавяне на интеграционен слой стигат за години напред. Казваме коя опция е разумна за твоя случай, включително когато е по-евтината.
Данните са по-ценни от кода. Първо гарантираме, че историята може да се извади и прехвърли, независимо какво решим за самата система.
Заменяме модул по модул, като старата и новата система работят заедно през преходния период. Пренаписване наведнъж е най-рисковият вариант и го избягваме.
Новата система идва с документация и достъп до хранилището. Целта е да не се озовеш след пет години в същата ситуация с друг доставчик.
Трябва ли изобщо пренаписване, какво става без изходен код, и как да не се повтори след пет години.
Не. Понякога стабилизиране, обновяване на средата и добавяне на интеграционен слой стигат за години. Пренаписване има смисъл, когато системата пречи на промени, които бизнесът вече изисква.
Тогава опциите се стесняват, но не изчезват. Данните почти винаги могат да се извадят от базата, а функционалността се възстановява по наблюдение на реалната употреба. Казваме честно колко по-скъпо излиза.
Заменяме модул по модул, а старата система остава активна за останалото. Пълно спиране за миграция избягваме — то е най-честата причина такива проекти да се провалят.
Не. Мигрирането на данните е първата стъпка, а не последната, и се прави с проверка срещу оригинала. Старата база се запазва като архив дори след пускането.
Три неща: изходният код и хранилището са твои, има документация, и системата е писана на технологии с активна поддръжка. Това не е гаранция, но премахва трите най-чести причини.
Опиши накратко какво прави и на какво стъпва — ще кажем дали изобщо си струва пренаписване.