Migracja ERP: kiedy chmura, a kiedy zostać on-prem

  • QData

TL;DR

  • Migracje ERP padają na integracji i przestoju, nie na rozmiarze VM — zmapujcie każde interface przed wyborem chmury lub on-prem.
  • Zostajcie on-prem przy latencji, OT i licencjach; idźcie w chmurę, gdy elastyczność, DR lub ścieżka SaaS jest jasna.
  • Hybryda często = rdzeń ERP on-prem + analityka lub portal w chmurze — nie dwa niedokończone migracje.
  • Wymagajcie właściciela rollbacku i testu restore przed oknem cutover na produkcji.

Dyrektor operacji miał piętnastoletni ERP, mocno customizowany, wciąż rentowny. Integrator proponował „cloud-first modernizację” w osiemnaście miesięcy. Hoster — podniesienie VM do managed cloud w sześć tygodni. Na slajdach strzałki w górę. Nikt nie wyjaśnił, co stanie się ze skanerami na hali, gdy moduł magazynowy się przeniesie, ani kto robi rollback, gdy zamknięcie miesiąca padnie w niedzielę.

Decyzje ERP u firm 50–200 osób to rzadko czysta chmura lub czysty on-prem. To ryzyko przestoju, integracji i odpowiedzialności. Ten poradnik daje macierz czterech osi — nie roadmapę vendora — przed budżetem od zarządu.

Cztery osie ważniejsze niż „chmura tak/nie”

  1. Tolerancja przestoju — weekend wystarczy? Potrzebujecie near-zero downtime?
  2. Powiązanie integracyjne — PLC, drukarki etyk, WMS, EDI, DLL, płaski L2?
  3. Licencje i compliance — reguły per-core w chmurze, rezydencja, regulator sektora?
  4. Dojrzałość operacyjna — właściciele ERP, DB, sieci — czy jeden generalista?

Niskie wyniki integracji i downtime → hybryda etapowa lub odświeżenie on-prem. Wysokie maturity i compliance → managed cloud lub SaaS — jeśli realny produkt istnieje.

Kiedy on-prem ma sens

Produkcja i logistyka trzymają ERP blisko linii. Regulowane branże wymagają on-prem lub sovereign cloud z udokumentowanym przepływem danych. Legacy z lat customizacji czasem tańsze ustabilizować na nowym sprzęcie niż refaktoryzować.

On-prem ≠ brak chmury. Najpierw AD, MFA, patch, backup offline, monitoring — potem portale i analityka w chmurze z udokumentowanymi interfejsami.

Kiedy wygrywa chmura lub hosting zarządzany

Elastyczne środowiska testowe bez kupowania serwerów co rok. DR gdy serwerownia bez generatora i bez testowanej kopii off-site. Wymiana EOL sprzętu, gdy vendor wspiera wersję ERP w managed VM. Przeniesienie sąsiednich workloadów (raporty, portal, pliki) przy tymczasowym ERP on-prem — częstszy sukces niż big-bang ERP.

Hybryda dobra vs „dwa problemy”

Dobra: ERP on-prem, nocne zanonimizowane extracty do BI, SSO z Entra, runbook incydentu per tier. Zła: ERP w chmurze, „tymczasowy” PostgreSQL na NAS, VPN hairpin dla każdego joba, dwie ekipy zrzucają winę na zamknięcie miesiąca.

Rollback i zamknięcie miesiąca

  • Nazwany decydent rollbacku (nie „komitet”).
  • Test restore bazy ERP w 30 dni z czasem trwania.
  • Blackout month-end uzgodniony z finansami.
  • Partnerzy integracyjni na standby z numerami eskalacji.

Co dalej

Wypiszcie systemy czytające/piszące do ERP. Oceńcie cztery osie z finansami, operacjami i IT. Jeden sąsiedni workload do chmury najpierw. Architektura i hosting: Usługi chmurowe; integracje sklepu i e-commerce: Aplikacje / E-commerce.

Chcesz porozmawiać o projekcie?

Kontakt

Więcej na ten temat

RFP na chmurę: jak porównać trzech dostawców bez porównywania prezentacji