Firma migruje workload SQL Server z on-premise do AWS. “Mamy już licencje, po prostu przeniesiemy.” Miesiąc później faktura z AWS: pełne koszty SQL Server licensing w EC2 - plus koszty on-premise licencji które dalej płacą (maintenance). Podwójne płacenie. Albo: mogliby użyć BYOL i płacić tylko za infrastructure.
Migracja do chmury zmienia ekonomikę licencji software. On-premise: kupujesz licencję raz (perpetual) lub płacisz subscription, hostujesz na swoim hardware. Cloud: często licensing jest wbudowany w koszt usługi (license-included) - ale to może być droższe niż BYOL (Bring Your Own License).
Przeczytaj także
- FinOps dla licencji software 2026: Jak połączyć SAM z zarządzaniem kosztami chmury?
- Audyt Oracle 2026: Jak przygotować firmę na weryfikację licencyjną?
- AI i automatyzacja w SAM: jak inteligentne zarządzanie licencjami może obniżyć twoje koszty IT o 30%?
Bez planowania licencyjnego, migracja może kosztować znacznie więcej niż zakładano. Z dobrym planowaniem - może być okazją do optymalizacji i oszczędności.
Jakie są podstawowe modele licencjonowania software w chmurze?
License-Included (LI): Cloud provider dostarcza software z wliczoną licencją. Płacisz za godzinę/miesiąc użycia. Prosty model, brak własnych licencji do zarządzania. Ale: często droższy w long-term.
Bring Your Own License (BYOL): Masz własne licencje (perpetual lub subscription), używasz ich w chmurze zamiast płacić cloud provider za licencję. Niższy koszt cloud (tylko infrastructure), ale musisz mieć licencje z odpowiednimi prawami.
Subscription z cloud provider: Kupujesz subscription bezpośrednio od vendora, ale delivery jest przez cloud. Np. Microsoft 365 (subscription od Microsoft, używana z Azure/anywhere).
Cloud-native pricing: Software ma dedykowane pricing dla cloud, inne niż on-premise. Np. Oracle Database w Oracle Cloud vs. on-premise licensing to różne modele.
Kiedy BYOL ma sens vs. License-Included?
BYOL ma sens gdy:
- Masz istniejące licencje z Software Assurance / aktywnym maintenance
- Długoterminowe użycie (3+ lata)
- High utilization (24/7 workloads)
- Masz prawo do mobility (sprawdź license terms)
License-Included ma sens gdy:
- Krótkoterminowe / variable workloads
- Nie masz istniejących licencji
- Testowanie / dev environments
- Chcesz simplicity (all-in-one billing)
Break-even analysis: Porównaj: (License-Included hourly rate × estimated hours) vs. (BYOL infrastructure rate × hours + license cost amortized)
Przykład:
- SQL Server License-Included na AWS EC2: $1.50/h
- BYOL infrastructure: $0.50/h + SQL Server license ($10,000/year amortized)
- At 8760h/year: LI = $13,140, BYOL = $4,380 + $10,000 = $14,380 → LI slightly better
- But: z Software Assurance which you already paid → BYOL is $4,380 total → much better
Jak Microsoft licensing działa w Azure vs. AWS vs. GCP?
Azure Hybrid Benefit (AHB): Masz Windows Server lub SQL Server z Software Assurance? Możesz użyć licencji w Azure bez dodatkowego kosztu licencyjnego - płacisz tylko za compute.
Savings: do 85% dla SQL Server, do 40% dla Windows Server.
AWS: BYOL możliwy dla Windows/SQL Server, ale wymaga dedicated hosts lub dedicated instances. Nie tak prosty jak Azure Hybrid Benefit. License Mobility dla niektórych Microsoft products.
GCP: Podobnie - BYOL wymaga sole-tenant nodes. Google oferuje też Cloud SQL z license-included.
Microsoft’s “Azure preferred”: Microsoft daje lepsze warunki dla Azure niż konkurencyjnych clouds. Azure Hybrid Benefit jest generous, BYOL do innych clouds ma więcej ograniczeń.
Jak Oracle licensing działa w chmurze - i dlaczego to pułapka?
Oracle licensing w cloud jest notoryjnie skomplikowane i często droższe niż on-premise.
Oracle Cloud Infrastructure (OCI): Licencjonowanie per OCPU (Oracle Compute Unit). BYOL możliwy. Oracle oferuje “discounts” żeby przyciągnąć do OCI.
Oracle w AWS/Azure/GCP: Oracle wymaga licencjonowania per vCPU z określonym multiplier (2 vCPU = 1 procesor Oracle). Ale uwaga: niektóre instance types wymagają więcej licencji niż byś oczekiwał.
AWS Dedicated Hosts: BYOL dla Oracle wymaga Dedicated Hosts (droższe niż shared). Licensing audits mogą kwestionować BYOL jeśli nie na dedicated.
Oracle authorized cloud environments: Oracle ma listę “authorized clouds” gdzie BYOL jest prostszy. AWS, Azure, GCP są authorized, ale zasady są szczegółowe.
Risk: Bez dokładnej analizy, Oracle w AWS może kosztować 2-3x więcej niż on-premise przez licensing complications.
Jakie są prawa mobility i jak je weryfikować?
License Mobility through Software Assurance (Microsoft): Masz licencje Microsoft z aktywnym SA → możesz przenosić do “shared servers” w authorized cloud. Ale: wymaga formy do wypełnienia, cloud provider musi być na liście.
Oracle mobility: Ograniczona. BYOL głównie do OCI. Do innych clouds - specyficzne warunki, często wymaga dedicated hosts.
SAP licensing w cloud: SAP pozwala na BYOL do certyfikowanych cloud providers. Wymaga: deklaracja, odpowiednie license type, monitoring użycia.
VMware w cloud: VMware Cloud on AWS, Azure VMware Solution - używasz swoich licencji lub kupujesz przez cloud. Specyficzne programy mobility.
Jak weryfikować:
- Sprawdź License Agreement - czy ma mobility rights
- Sprawdź Software Assurance status (Microsoft)
- Sprawdź cloud provider w liście authorized
- Dokumentuj deployment - audits mogą wymagać dowodów
Jak zaplanować migrację licencji krok po kroku?
Krok 1: Inventory Lista wszystkich software które będzie migrowane. Jakie licencje masz, jakie entitlements, jaki SA/maintenance status.
Krok 2: Target architecture Jak software będzie deployed w cloud? Instance sizes, regions, availability zones. To wpływa na licensing.
Krok 3: Licensing options analysis Dla każdego software: BYOL możliwy? License-Included available? Warunki, ograniczenia, koszty.
Krok 4: Cost comparison Porównaj: current on-prem licensing cost + new cloud infrastructure cost + any additional cloud licensing cost. Vs. license-included total cost. Vs. renegotiated cloud-native licensing.
Krok 5: Rights verification Sprawdź że masz prawa do BYOL. Fill required forms. Notify vendors.
Krok 6: Vendor negotiation Migracja to okazja do renegocjacji. “Migrujemy do Azure, chcemy better Azure terms.” Vendors chcą cloud business.
Krok 7: Implementation with license tracking Deploy z odpowiednim tagging dla license tracking. Monitor usage vs. entitlements.
Krok 8: Post-migration audit Sprawdź że faktyczne deployment = planned. Czy licencje są prawidłowo używane.
Jakie są common mistakes i jak ich unikać?
Zakładanie że BYOL jest automatic. Nie jest. Wymaga: odpowiednich praw, odpowiedniego deployment (dedicated hosts dla niektórych), dokumentacji.
Ignoring cloud provider licensing. AWS Marketplace, Azure Marketplace mają software z own licensing. Upewnij się że rozumiesz model przed purchase.
Forgetting maintenance/support. BYOL to license, ale support może być osobny. On-prem support agreement może nie obejmować cloud deployment. Sprawdź!
Not considering cloud-native alternatives. Zamiast SQL Server w EC2 - może Aurora (AWS cloud-native)? Zamiast Oracle - może PostgreSQL? Migracja to okazja do zmiany.
Underestimating Oracle complexity. Oracle w non-Oracle cloud jest licensing minefield. Expert advice recommended.
No tagging for license tracking. Cloud resources bez tagów = trudne do matchowania z licencjami. Tag wszystko: product, version, license type.
Jak negocjować z vendorami przy okazji migracji?
Leverage migration moment: “Migrujemy dużą część workloads do cloud. Chcemy rozmawiać o cloud-friendly licensing.” Vendor wie że może stracić business do cloud-native alternatives.
Consolidate and negotiate: Masz licencje u Microsoft, Oracle, SAP? Migrując, rozmawiaj ze wszystkimi. Może jeden da lepszą ofertę za większy share.
Ask for migration incentives: Microsoft, Oracle, SAP mają programy zachęcające do ich clouds. Azure migrate credits, Oracle cloud migration support.
Consider term alignment: Licencje renewal w różnych terminach? Migracja to okazja do aligned terms (jeden vendor negotiation per year, not four).
Get benchmark data: Co inni płacą za similar migration? Use consultants, Gartner, peer networks.
Tabela: Licensing Considerations by Major Vendor in Cloud
| Vendor | BYOL Options | Best Cloud for BYOL | Key Considerations | Pitfalls |
|---|---|---|---|---|
| Microsoft (Windows Server) | Yes with SA | Azure (Hybrid Benefit) | 40% savings possible, easy process | AWS/GCP require dedicated hosts |
| Microsoft (SQL Server) | Yes with SA | Azure (Hybrid Benefit) | Up to 85% savings | Core counting, edition matching |
| Oracle Database | Limited | OCI preferred | Processor counting rules complex | Non-OCI clouds very expensive |
| SAP | Yes with conditions | All major clouds certified | Requires declaration, proper license type | Named User vs. Engine licensing |
| VMware | Via VMware Cloud programs | AWS, Azure VMware Solution | Subscription or BYOL | vCPU counting for licensing |
| Red Hat | Yes | All clouds | Simple BYOL, also cloud marketplace | Ensure support continuity |
Migracja do chmury bez planowania licencyjnego to przepis na cost overruns. Z dobrym planowaniem, BYOL i vendor negotiations - to okazja do optymalizacji. Różnica może być 30-50% total cost.
Kluczowe wnioski:
- BYOL może znacząco obniżyć cloud costs - ale wymaga odpowiednich praw
- Azure Hybrid Benefit jest generous dla Microsoft workloads
- Oracle w non-Oracle cloud to expensive proposition - plan carefully
- License mobility wymaga weryfikacji i dokumentacji
- Migracja to negotiation opportunity - vendors chcą cloud business
- Track licenses w cloud przez tagging - audits nadal są realne
- Consider cloud-native alternatives - nie wszystko musi być lift-and-shift
Zaangażuj licensing expertise early w migration planning. To investment który zwraca się wielokrotnie.
ARDURA Consulting oferuje kompleksowe wsparcie Software Asset Management przy migracjach do chmury. Pomagamy planować licensing, negocjować z vendorami i optymalizować koszty software w cloud. Skontaktuj się z nami przed rozpoczęciem migracji.