• Kezdőlap
  • Megoldásaink
  • Esettanulmáyok
  • Kapcsolat
  • MI AZ A PROBLÉMA,
    AMIRE MEGOLDÁST
    KERES?

    Az alábbi oldalon végigvezetjük, hogy melyik helyzetre mi a pontos folyamat, meddig tart, és mit kap a végén. „Írjuk újra az egészet" helyett feltárjuk az egyedi problémát, és fokozatos megoldást kínálunk.

    Vagy ugorjon közvetlenül a helyzetéhez a lenti menüben ↓

    20+ átvett rendszer 10 év tapasztalat 99.7% üzemidő-garancia 24/7 NOC

    „A működő rendszereket nem lecseréljük. Továbbfejlesztjük."

    Ez nem marketingszöveg. Minden projekt első percétől azt kutatjuk, hogy mit tarthatunk meg, mit kell stabilizálni, és hol van szükség modernizálásra. 10 év alatt egyetlen ügyfélnek sem javasoltunk teljes újraírást, ha volt más út.

    Átkötjük PHP 8-ra úgy, hogy közben megy a rendszer.

    Ultimátumot kapott a szolgáltatótól, és a rendszere nem fut az új verzión.

    A tárhelyszolgáltatónk 30 napot adott, hogy elhagyjuk a PHP 5-öt. A rendszerünk nem fut az új verzión — ha nem lépünk, lekapcsolják.

    Ez nem egy új rendszer megírását jelenti. Átvizsgáljuk a kódbázist, azonosítjuk a deprecated függvényeket, újraírjuk a kritikus részeket modern szintaxissal, és párhuzamos tesztkörnyezetben validáljuk élesítés előtt. Mindezt úgy, hogy közben a rendszer nem áll le.

    Mikor sürgős
    • PHP ultimátumot kapott a tárhelyszolgáltatótól
    • A rendszer lassabb szerveren fut, mert nem frissíthető
    • Biztonsági rések a régi PHP verzióban
    • Kompatibilitási hibák jelennek meg az éles rendszeren
    A folyamat
    1. 01 Kódbázis átvizsgálása — automatizált analízis + manuális review
    2. 02 Inkompatibilis részek azonosítása — ami nem fut PHP 8-on
    3. 03 Szükséges módosítások — kis, visszagörgethető commit-okban
    4. 04 Tesztelés staging környezetben — teljes funkcionális validáció
    5. 05 Stabil átállás élesben — tervezett időablakban, fallback-kel biztosítva
    Jellemző határidő 2–6 hét, a kódbázis méretétől függően.
    Eredmény
    • A rendszer a tárhely által támogatott PHP verzión fut
    • 0 rendszerleállás az átállás alatt
    • +40% átlagos teljesítmény-javulás
    • A régi biztonsági rések lezárva

    Átvesszük a felelősséget ott, ahol az előző csapat abbahagyta.

    A rendszer gazdátlanná vált, nincs dokumentáció, nincs aki értse a kódot.

    A cég, aki megírta a rendszerünket, megszűnt. Dokumentáció nincs. Senki nem mer hozzányúlni. A rendszer viszont minden nap megy — és nélküle nincs cégünk.

    Eddig 20+ rendszernél hallottuk ugyanezt a mondatot: „Ha megmutatnám a kódot, rosszul lenne." Nem leszünk rosszul. Van egy standardizált átvételi protokollunk, ami pontosan arra az esetre készült, amikor nincs dokumentáció és senki nem akar hozzányúlni. Az első két hétben nem írunk kódot — csak feltérképezünk.

    Ismerős helyzet
    • Eltűnt a fejlesztő, megszűnt a fejlesztő cég
    • Nincs dokumentáció, nincs rendszer-leírás
    • Senki nem mer hozzányúlni a kódhoz
    • Az egyetlen ember, aki értette, már nem elérhető

    Amikor a régi fejlesztőcsapat megszűnt, komoly kockázatot jelentett a rendszer további működése. A Binary rövid idő alatt átlátta a kódbázist és átvette az üzemeltetést.

    Ügyvezető, logisztikai cég
    Az átvétel folyamata
    1. 01 Rendszer működésének elemzése — futó környezet, log-elemzés
    2. 02 Kódstruktúra feltérképezése — automatizált + kézi analízis
    3. 03 Üzleti folyamatok feltárása — interjúk a kulcsfelhasználókkal
    4. 04 Kockázati mátrix + prioritási lista — 2 héten belül
    5. 05 Dokumentáció készítése — amit Önnek is átadunk
    6. 06 Üzemeltetés átvétele — SLA-szerződéssel, 24/7 NOC-cal
    Jellemző határidő 2 hét a kockázati mátrixra, 30 nap a stabil üzemeltetésig.
    Eredmény
    • Teljes, dokumentált rendszer-leltár
    • 100% kódtulajdon marad az ügyfélé
    • Dedikált csapat az egyetlen fejlesztő helyett
    • Megszűnik az „egyetlen emberen múlik minden" kockázat

    Stabil alapra állítjuk a rendszert, amíg még nem ég a ház.

    Lassulás, kompatibilitási gondok, véletlenszerű hibák jelennek meg.

    A rendszer megy, de minden hónapban több a hiba, és már senki sem biztos benne, miért. Félünk hozzányúlni, de így se mehet sokáig.

    Ez a „még nem késő, de már füstöl" forgatókönyv. 5–10+ éves, többfejlesztős, dokumentálatlan rendszerek tipikus élete. A stabilizálás célja, hogy a rendszer ne a legrosszabb pillanatban omoljon össze, hanem szabályozott, megelőző beavatkozással hozzuk rendbe.

    Különösen gyakori, ha
    • Több mint 5–10 éve készült a rendszer
    • Több fejlesztő dolgozott rajta az évek alatt
    • Már nem teljesen támogatott technológiára épül
    • Egyre gyakrabban jelennek meg hibák, lassulás, gondok
    A folyamat
    1. 01 Rendszer audit és állapotfelmérés — hol vannak a legnagyobb kockázatok
    2. 02 Kritikus hibák javítása — ami most aktívan fájdalmat okoz
    3. 03 Teljesítmény-problémák feltárása — mérés, nem találgatás
    4. 04 Működésbiztonság javítása — biztonsági rések, hibatűrés
    5. 05 Alap-dokumentáció készítése — hogy legyen mit átadni a következő szakaszban
    Jellemző határidő 30 nap a stabil alapokig.
    Eredmény
    • Stabilabb, kiszámíthatóbb rendszer
    • A napi működés biztonságosan folytatható
    • A rendszer továbbfejleszthető — nem minden változtatás kockázat
    • Dokumentált állapot és kockázati mátrix

    Van. Megtartjuk a régi alapot, fölé / köré / mellé építjük az újat.

    Új integráció, fejlesztés vagy mobilapp kell — anélkül, hogy cserélni kéne az alapokat.

    Új CRM-et vettünk, mobilapp kellene, be kéne kötni a webshopra — de a belső rendszert nem tudjuk vagy nem akarjuk kicserélni. Van más út?

    A modernizálás nálunk nem azt jelenti, hogy „kezdjük elölről". Azt jelenti, hogy megértjük, mi az, ami nélkülözhetetlen a jelenlegi rendszerben, és csak a körülötte lévő dolgokat frissítjük. API wrapper, új frontend, integrációs réteg, konténerizálás — minden a meglévő logika védelme érdekében.

    Ez a helyes út, ha
    • Új funkciókat kell fejleszteni, de nem akarja kockáztatni a stabil magot
    • Integráció kell más rendszerekhez (CRM, webshop, ERP, számlázó)
    • Teljesítményjavítás szükséges
    • Modern technológiákat (konténer, CI/CD, monitoring) kell bevezetni
    A modernizálás menete
    1. 01 Meglévő rendszer üzleti logikájának feltérképezése
    2. 02 Modernizálási terv — mi marad, mi változik, mi épül köré
    3. 03 API wrapper / Digitális Híd fejlesztése
    4. 04 Fokozatos integráció — kis lépésekben, visszagörgethető
    5. 05 Párhuzamos futtatás és validálás
    6. 06 Stabil átadás — teljeskörű dokumentációval
    Jellemző határidő 3–9 hónap, fokozatosan.
    Eredmény
    • A régi üzleti logika megőrizve
    • Új funkciók vagy integrációk élőben működnek
    • Kisebb kockázat és töredékes költség a teljes újraíráshoz képest
    • Folyamatos működés a fejlesztés teljes ideje alatt

    Új rendszer épül, miközben a régi még megy.

    Sok az új igény, de az architektúra már nem bír el többet.

    Már annyi új igényünk van, hogy a régi rendszer egyszerűen nem bír el többet. De a teljes újraírás hónapokig leállítana minket.

    Amikor a jelenlegi architektúra már objektíven nem fejleszthető tovább, akkor sem a „kapcsoljuk ki hétvégén, kapcsoljuk be hétfőn" forgatókönyv jön. Egy fokozatos újraépítés során az új rendszer modulról modulra épül fel, a régivel párhuzamosan fut, és a felhasználók részenként állnak át. Ezt a gyakorlatot hívják Strangler Fig pattern-nek.

    Mikor ez a helyes út
    • A jelenlegi technológia objektíven nem bír el több üzleti igényt
    • De a teljes egyszeri csere túl nagy kockázat
    • Szükség van a folyamatos működésre a teljes projekt alatt
    • A költségeket tervezhető módon kell keretbe illeszteni
    Hogyan működik
    1. 01 Jelenlegi rendszer állapotának felmérése — mi tartható, mi nem
    2. 02 Újraépítési ütemterv — modulok, prioritások, migrálási sorrend
    3. 03 Az első modulok párhuzamos fejlesztése — kommunikál a régivel
    4. 04 Fokozatos átállás szekciónként — felhasználók csoportonként mennek át
    5. 05 Régi rendszer leállítása modulonként — csak ha már senki nem használja
    Jellemző határidő 12–24 hónap, szekciónként.
    Eredmény
    • Nincs hirtelen átállási kockázat — minden modul külön kerül élesbe
    • A vállalat folyamatosan működik a teljes projekt alatt
    • Az első modulok 3–6 hónapon belül már termelnek
    • Tervezhető költség havi / negyedéves ütemezésben

    Megszüntetjük a „csak egy ember tudja" kockázatot — 24/7 NOC-csal és 99.7% uptime SLA-val.

    Megbízható, SLA-val ellátott üzemeltető partner kell.

    Elegünk van abból, hogy egy szabadúszó hangulata dönti el, üzemel-e a rendszer holnap. SLA-ra és hívható csapatra van szükségünk.

    Az üzemeltetés a folyamatos kísérő szolgáltatás a többi megoldás mellett. Nem kivételes beavatkozás, hanem a napi normál: valaki figyeli a logokat, csinálja a mentéseket, telepíti a patch-eket, és 1 munkanapon belül reagál, ha valami történik.

    Különösen kritikus, ha
    • A rendszer közvetlenül a cég napi működését szolgálja
    • Egy napi leállás érzékelhető üzleti kár
    • Adminisztráció, rendelésfeldolgozás, számlázás fut rajta
    • Eddig egyetlen szabadúszóra volt bízva a felügyelet
    Mit tartalmaz
    1. 01 24/7 rendszer-monitorozás — NOC csapat, proaktív észlelés
    2. 02 Hibakezelés SLA szerint — válaszidő és javítási idő szerződésben
    3. 03 Kisebb fejlesztések és javítások — ami menet közben merül fel
    4. 04 Szerverkompatibilitás biztosítása — infrastruktúraváltozásokra is figyelünk
    5. 05 Technikai támogatás — belső csapatnak és külső partnereknek
    Jellemző határidő Folyamatos, havi fix díjas megállapodás.
    Eredmény
    • 99.7% garantált üzemidő (SLA-ban rögzítve)
    • 1 munkanapos válaszidő minden nem-vészhelyzeti esetre
    • 24/7 NOC sürgős események kezelésére
    • Fix havi díj, rejtett költségek nélkül

    MELYIK MEGOLDÁS
    AZ ÖNÉ?

    Nem biztos benne? Pontosan emiatt indulunk mindig egy 2 órás ingyenes felméréssel — megnézzük a rendszert, elmondjuk a javaslatunkat.

    Helyzet Megoldás Jellemző időtáv Szint
    PHP ultimátum, migráció szükséges PHP frissítés → 2–6 hét Kód-szint
    Eltűnt fejlesztő, nincs dokumentáció Rendszerátvétel → 2 hét audit, 30 nap stabil Teljes átvétel
    „Működik, de sok a hiba és lassú" Stabilizálás → 30 nap Rendszer-szint
    Új funkció vagy integráció kell Modernizálás → 3–9 hónap, fokozatosan Architektúra-szint
    Az alapok már nem fejleszthetők Fokozatos újraépítés → 12–24 hónap, szekciónként Stratégiai szint
    Napi üzemeltető partner kell Üzemeltetés (NOC+SLA) → Folyamatos, havi díjas Bármely fázisban

    ÍGY NÉZT KI
    A GYAKORLATBAN

    4 konkrét eset — mindegyik egy 10+ éves rendszer, mindegyik egy valódi vészhelyzet.

    Önkormányzati dokumentumkezelő

    Régi PHP, érzékeny adatok, biztonsági audit előtt

    Stabilizálás + PHP-frissítés kombinációja.

    0 biztonsági incidens 100% dokumentum-integritás +50% admin gyorsulás
    Technorgaz — Az örökség súlya

    10+ éves üzleti rendszer PHP 5-ön, jövőbe mutató platform kellett

    Fokozatos modernizálás — 0 állásidővel.

    PHP 8 platform 10+ év rendszerélettartam 0 állásidő
    A Digitális Híd

    Régi ERP + modern WooCommerce, napi manuális szinkronizálás

    Modernizálás + integrációs réteg fejlesztése.

    100% automatizált rendelés 2× kapacitás 0 manuális adatbevitel
    Bálintzár Kft.

    Tárhelyszolgáltató lekapcsolta az infrastruktúrát

    PHP-frissítés + stabilizálás — napokon belüli beavatkozás.

    0 állásidő 100% szerverkompatibilitás +40% teljesítmény

    GYIK

    „Mi van, ha több is érvényes a helyzetemre? Pl. eltűnt a fejlesztő ÉS PHP ultimátum is van?"

    A legtöbb projektünk pont ilyen kombinált eset. Először felmérünk: az ingyenes 2 órás konzultáció pont arra való, hogy eldöntsük, milyen sorrendben érdemes haladni. A PHP-frissítést például nem kezdjük el átvétel nélkül, mert nem értjük, mit frissítünk.

    „Honnan tudjátok, melyik a jó megoldás, ha még meg sem néztétek a rendszert?"

    Nem is tudjuk, és pont ezért nem adunk árajánlatot vakon. A 2 órás felmérés után mondunk véleményt. Ha úgy látjuk, hogy a legjobb lépés nem a Binary-vel való együttműködés, azt is megmondjuk.

    „Mennyibe kerül egy ilyen beavatkozás?"

    A felmérés ingyenes. A beavatkozás költsége fix büdzsé-alapon kerül meghatározásra, a kódbázis méretétől és komplexitásától függően. A legtöbb átvételi és stabilizálási projekt a teljes újraírás 10–20%-a költségszinten. A pontos árról a felmérés után adunk ajánlatot, rejtett költségek nélkül.

    „Mi történik, ha Önök nyúlnak hozzá és tönkremegy?"

    Minden beavatkozás staging környezetben zajlik, konténerizálva, visszaállítható lépésekben. Az éles rendszert addig nem érintjük, amíg a változtatás ott nem validált. 20+ átvételnél eddig 0 rendszerleállás. SLA-t is vállalunk az éles környezet stabilitására.

    „Utána Önökhöz leszünk kötve?"

    Nem. Minden kód, dokumentáció és hozzáférés az Öné marad — ezt írásban is rögzítjük. Nincs proprietary framework, nincs licenc-csapda. Ha egy év múlva másik céggel dolgozna, átadjuk a teljes dokumentált rendszert.

    Ha bármelyik helyzet
    ismerős volt, a 2 óra
    fontos kezdet.

    → Állapotfelmérés a rendszeréről
    → Diagnózis: melyik megoldás illik a helyzetére
    → Előzetes ajánlat-keret, ha van értelme továbbmenni
    → Minden kötelezettség nélkül.

    Nem várjuk, hogy ma aláírjon bármit. A 2 órás beszélgetés során megnézzük a rendszerét, átbeszéljük a kritikus pontokat, és elmondjuk, melyik megoldás lenne a legcélszerűbb — függetlenül attól, hogy minket bíz-e meg.

    Kérek egy felmérést →

    1 munkanapon belüli válasz  ·  Magyar csapat  ·  Fix büdzsé, rejtett költségek nélkül  ·  Kötelezettségmentes