Migration & Upgrade Strategy

Migration & upgrade strategy - bu Spring Boot yoki Java application’ni yangi versiyaga ko‘chirishni "dependency versionni almashtirish" deb emas, risk boshqaruvi, compatibility, rollout, test va rollback strategiyasi sifatida ko‘rish.

Bu mavzu quyidagilarni o‘z ichiga oladi: Spring Boot 2 → 3 migration path, Java EE / Jakarta EE namespace migration, Strangler Fig pattern, dependency convergence & CVE management, va API backward compatibility.

1. Migration nima?

Migration - tizimni eski texnologik holatdan yangi holatga ko‘chirish.

Misollar:

Spring Boot 2.7 → Spring Boot 3.x
Java 11 → Java 17 / 21
javax.* → jakarta.*
Spring Security 5 → Spring Security 6
Hibernate 5 → Hibernate 6
Monolith → Modular monolith
Monolith → Microservices
REST API v1 → REST API v2
Old database schema → new database schema

Arxitektor savoli:

"Qanday qilib tizimni yangilaymiz, lekin production’ni buzmaymiz?"

2. Upgrade nima?

Upgrade - mavjud dependency, framework yoki runtime’ni yangi versiyaga ko‘tarish.

Masalan:

<spring-boot.version>2.7.18</spring-boot.version>

dan:

<spring-boot.version>3.3.x</spring-boot.version>

yoki:

<spring-boot.version>3.5.x</spring-boot.version>

ga o‘tish.

Spring Boot rasmiy upgrade hujjatlarida 2.x’dan ko‘tarilishda Spring Boot migration guide va release notes’ni tekshirish tavsiya qilinadi. (Home)

3. Arxitektor darajada migration nimani anglatadi?

Developerlar odatda ko‘pincha shunday o‘ylaydi:

versionni almashtiramiz
compile errorlarni tuzatamiz
testdan o‘tkazamiz
deploy qilamiz

Arxitektorlar esa kengroq qaraydi:

qaysi service birinchi upgrade qilinadi?
qaysi dependencylar conflict beradi?
qaysi API backward compatible qoladi?
rollback qanday bo‘ladi?
database migration qaytariladimi?
clientlar buzilmaydimi?
security patchlar yopildimi?
monitoring migrationdan keyin ishlaydimi?

Ya’ni migration - texnik refactor emas, production risk management.

4. Nega upgrade strategiya kerak?

Agar upgrade tartibsiz qilinsa:

service compile bo‘lmaydi
runtime’da ClassNotFoundException chiqadi
javax/jakarta conflict bo‘ladi
security config buziladi
Hibernate querylar boshqacha ishlaydi
API response o‘zgarib ketadi
clientlar yiqiladi
rollback qiyinlashadi

Katta system’da eng xavfli holat:

"Hammasini bir PR’da upgrade qilamiz."

To‘g‘ri strategiya:

audit
step-by-step upgrade
compatibility layer
test coverage
canary rollout
monitoring
rollback plan

5. Spring Boot 2 → 3 migration path

Spring Boot 3 migration eng katta o‘zgarishlardan biri, chunki u:

Java 17+ talab qiladi
Spring Framework 6 asosida ishlaydi
Jakarta EE 9 API ishlatadi
javax.* o‘rniga jakarta.* ishlatadi
Spring Security 6 o‘zgarishlari bor
Hibernate 6 o‘zgarishlari bor

Spring jamoasi Spring Boot 3.0 Spring Framework 6.0 asosida bo‘lishi, Java 17 yoki undan yuqorini talab qilishi va Jakarta EE 9 jakarta.* API’lariga o‘tishini e’lon qilgan. (Home)

Tavsiya migration yo‘li

Spring Boot 3 migration guide Spring Boot 3.0'ga o‘tishdan oldin eng oxirgi 2.7.x versiyaga upgrade qilishni tavsiya qiladi. (GitHub)

Amaliy yo‘l:

1. Spring Boot 2.x ichida eng oxirgi 2.7.x ga o‘tish
2. Java versionni 17+ qilish
3. Deprecated API’larni tozalash
4. Spring Security 5.8 migration qilish
5. javax.* importlarni jakarta.* ga tayyorlash
6. Third-party dependency compatibility tekshirish
7. Spring Boot 3.x ga o‘tish
8. Hibernate 6 / Security 6 / validation o‘zgarishlarini tuzatish
9. Full regression test
10. Canary deploy

6. Nega avval 2.7.x?

Agar biz to‘g‘ridan-to‘g‘ri eski 2.3 yoki 2.4'dan Boot 3'ga o‘tsangiz, xatolar juda ko‘payadi.

Yomon:

Spring Boot 2.3 → Spring Boot 3.3

Yaxshi:

Spring Boot 2.3 → 2.7.x → 3.x

Sabab:

2.7.x migration warninglarni beradi
deprecated API’larni ko‘rish osonlashadi
dependencylar Boot 3 ga yaqinlashadi
Security 5.8 orqali Security 6 ga tayyorlanadi

7. Java EE → Jakarta EE migration

Spring Boot 3 bilan katta o‘zgarish:

javax.* → jakarta.*

Masalan:

import javax.persistence.Entity;
import javax.validation.Valid;
import javax.servlet.Filter;

bo‘ladi:

import jakarta.persistence.Entity;
import jakarta.validation.Valid;
import jakarta.servlet.Filter;

Bu oddiy import almashtirishga o‘xshaydi, lekin real project’da katta ta’sir qiladi.

Ta’sir qiladigan joylar

JPA entities
Bean Validation
Servlet API
JAX-RS
JMS
JSON-B
XML binding
third-party libraries
generated code
OpenAPI generated models

Misol:

import javax.persistence.Entity;
import javax.persistence.Id;

yangisi:

import jakarta.persistence.Entity;
import jakarta.persistence.Id;

8. Eng ko‘p chiqadigan muammo: dependency conflict

Boot 3 jakarta.* ishlatadi. Lekin ba’zi eski librarylar hali ham javax.* ishlatadi.

Muammo:

Application Boot 3'da
lekin eski dependency javax.servlet.Filter kutyapti
runtime’da ClassNotFoundException chiqadi

Yechim:

librarylarni Boot 3 compatible versiyaga ko‘tarish
eski libraryni almashtirish
generated clientlarni qayta generate qilish
javax/jakarta aralashmasini tozalash

9. OpenRewrite bilan migration

Katta codebase’da qo‘lda import almashtirish xavfli va sekin.

OpenRewrite Spring Boot 3 migration recipe’lari build files, deprecated/preferred API, configuration settings va framework migrationlarni avtomatik o‘zgartirishga yordam beradi. (OpenRewrite Docs)

Masalan migration yordam berishi mumkin:

javax → jakarta importlar
Spring Boot version update
deprecated property migration
Spring Security DSL update
old API’dan new API’ga o‘tish

Lekin qoida:

OpenRewrite migrationni tezlashtiradi, lekin arxitektor qarorini almashtirmaydi. Har doim review, test va rollout kerak.

10. Migration branch strategy

Katta upgrade uchun yaxshi branch strategiya:

main
 ├── migration/spring-boot-3
      ├── step-1-java-17
      ├── step-2-boot-2.7-latest
      ├── step-3-jakarta
      ├── step-4-security-6
      └── step-5-boot-3

Yoki kichik PR’lar:

PR 1: Java 17 support
PR 2: Deprecated API cleanup
PR 3: Dependency alignment
PR 4: javax → jakarta
PR 5: Spring Security migration
PR 6: Hibernate fixes
PR 7: Boot 3 switch

Yomon amaliyot:

500 ta file o‘zgargan bitta ulkan PR

Bunday PR review qilish qiyin, rollback qilish qiyin.

11. Spring Security migration

Spring Security 6'da eski config yondashuvlar ko‘p o‘zgargan.

Eski uslub:

@EnableWebSecurity
public class SecurityConfig extends WebSecurityConfigurerAdapter {
}

Yangi uslub:

@Configuration
@EnableWebSecurity
public class SecurityConfig {

    @Bean
    SecurityFilterChain securityFilterChain(HttpSecurity http) throws Exception {
        return http
                .authorizeHttpRequests(auth -> auth
                        .requestMatchers("/actuator/health").permitAll()
                        .anyRequest().authenticated()
                )
                .oauth2ResourceServer(oauth -> oauth.jwt())
                .build();
    }
}

Migration’da quyidagilarni tekshirish kerak:

endpoint authorization
CSRF policy
CORS
JWT claim mapping
role prefix
method security
password encoder
actuator security

Security migration’da eng xavfli narsa:

Application compile bo‘lishi mumkin, lekin security behavior o‘zgarib ketadi.

12. Hibernate 5 → 6 migration

Spring Boot 3 odatda Hibernate 6 bilan keladi.

Tekshiriladigan joylar:

custom queries
native queries
JPQL syntax
dialect settings
custom UserType
pagination behavior
naming strategy
lazy loading
criteria API

Agar projectda ko‘p custom query bo‘lsa, migration risk yuqori.

Testlar:

repository integration tests
Testcontainers bilan real database
migration scripts
slow query monitoring
N+1 checks

13. Configuration property migration

Spring Boot versiyalarda property nomlari o‘zgarishi mumkin.

Masalan:

management.metrics.export.prometheus.enabled: true

ba’zi versiyalarda boshqacha konfiguratsiyaga o‘tgan bo‘lishi mumkin.

Migration strategy:

old propertylarni scan qilish
metadata warninglarni ko‘rish
startup loglarni tekshirish
deprecated config report olish
configuration tests yozish

Spring Boot release notes va migration guide har release uchun "breaking change" va property o‘zgarishlarini tekshirishda asosiy manba bo‘ladi. (Home)

14. Dependency convergence

Dependency convergence - project ichida bir xil library’ning turli versiyalari conflict qilmasligi.

Masalan:

service A:
  jackson-databind 2.15

dependency X:
  jackson-databind 2.13

dependency Y:
  jackson-databind 2.16

Natija:

NoSuchMethodError
ClassCastException
runtime conflict
security vulnerability

Arxitektor darajada yechim:

BOM ishlatish
dependencyManagement markazlashtirish
Maven Enforcer / Gradle constraints
dependency tree audit
CI’da vulnerability scan

15. BOM orqali boshqarish

Platform standardization mavzusida aytganimizdek, company BOM dependency versionlarni markazlashtiradi.

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>com.company.platform</groupId>
            <artifactId>company-bom</artifactId>
            <version>2.0.0</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Foyda:

hamma service bir xil dependency baseline’da
CVE patch markazdan qilinadi
upgrade PR’lar standart bo‘ladi
conflict kamayadi

16. CVE management

CVE - dependency yoki platformadagi xavfsizlik zaifligi.

Masalan:

Jackson CVE
Netty CVE
Tomcat CVE
Spring Security CVE
Logback CVE
PostgreSQL driver CVE

CVE strategy:

1. SBOM generate qilish
2. Dependency scan qilish
3. Severity bo‘yicha triage
4. Exploitability tekshirish
5. Patched versionga upgrade
6. Regression test
7. Rollout
8. Audit record

Spring OSS support policy’da major release’lar 3 yilgacha, minor release’lar esa kamida 12 oy qo‘llab-quvvatlanishi aytilgan. (Home) Shuning uchun arxitektor faqat "hozir ishlayapti" deb emas, support lifecycle bo‘yicha ham reja qiladi.

17. Release cadence & EOL planning

EOL - End of Life. Ya’ni versiya endi free public security/bug fix olmaydi.

Arxitektor har service uchun matrix yuritadi:

Yaxshi platform governance:

har quarter dependency review
EOL’dan 6 oy oldin migration plan
critical CVE bo‘lsa emergency patch
major upgrade uchun pilot service

18. Strangler Fig Pattern

Strangler Fig pattern - legacy systemni birdan rewrite qilmasdan, sekin-sekin yangi system bilan almashtirish.

G‘oya:

Old monolith saqlanadi
yangi featurelar yangi service/module’da yoziladi
traffic asta-sekin yangi tomonga yo‘naltiriladi
legacy qismi qisqarib boradi
oxiri eski qism o‘chiriladi

Oddiy ko‘rinish

Client
  ↓
API Gateway
  ├── /old/orders  → legacy monolith
  ├── /new/orders  → new order service
  └── /payments    → new payment service

Yoki:

/orders eski read → legacy
/orders yangi write → new service

19. Strangler Fig qachon kerak?

Kerak bo‘ladi:

katta monolith bor
rewrite xavfli
business to‘xtamasligi kerak
domainlarni asta ajratish kerak
teamlar parallel ishlashi kerak
legacy code test qilinmaydi

Kerak bo‘lmasligi mumkin:

kichik project
legacy juda oddiy
full rewrite tez va xavfsiz
business critical emas

20. Strangler migration bosqichlari

1. Legacy system boundary mapping
2. Domain/module tanlash
3. API gateway/proxy qo‘yish
4. Yangi module/service yaratish
5. Data sync strategiya tanlash
6. Traffic routing
7. Dual-write yoki event sync
8. Canary rollout
9. Legacy endpointni deprecated qilish
10. Eski kodni olib tashlash

21. Eng xavfli qism: data migration

Legacy’dan yangi systemga o‘tishda data masalasi eng qiyin.

Variantlar:

Big bang migration
Dual-write
CDC - Change Data Capture
Event-driven sync
Read from legacy, write to new
Read from new, fallback to legacy

Big bang

Bir kechada hamma data ko‘chiriladi
old system o‘chadi
new system yoqiladi

Risk yuqori.

Dual-write

Application eski DB va yangi DB’ga yozadi

Risk:

biri yozildi, biri yozilmadi
consistency muammosi
rollback qiyin

CDC

Legacy database change log → Debezium → Kafka → new system

Ko‘p enterprise migrationlarda CDC xavfsizroq bo‘lishi mumkin.

22. API backward compatibility

Upgrade vaqtida eng muhim qoidalardan biri:

Existing clientlar buzilmasligi kerak.

Breaking change misollar:

field nomi o‘zgardi
enum value o‘zgardi
required field qo‘shildi
response structure o‘zgardi
HTTP status o‘zgardi
pagination format o‘zgardi
error response o‘zgardi
auth scope o‘zgardi

Yomon:

{
  "userName": "Ali"
}

yangisi:

{
  "fullName": "Ali"
}

Bu clientni buzadi.

Yaxshi:

{
  "userName": "Ali",
  "fullName": "Ali"
}

keyin deprecation period.

23. API versioning strategy

Variantlar:

URI versioning

/api/v1/orders
/api/v2/orders

Sodda va tushunarli.

Header versioning

Accept: application/vnd.company.orders-v2+json

Toza, lekin clientlar uchun murakkabroq.

Compatible evolution

Bitta endpoint, faqat backward compatible o‘zgarishlar.

field qo‘shish mumkin
field o‘chirish mumkin emas
required qilish mumkin emas
enumni ehtiyot bilan kengaytirish kerak

24. Backward compatible o‘zgarishlar

Odatda xavfsiz:

response’ga optional field qo‘shish
yangi endpoint qo‘shish
yangi optional request field qo‘shish
pagination metadata qo‘shish
new enum value - ehtiyot bilan

Xavfli:

field rename
field remove
type change
required field qo‘shish
error code o‘zgartirish
HTTP status o‘zgartirish
auth requirement kuchaytirish

25. Deprecation policy

Har API uchun deprecation qoidasi bo‘lishi kerak:

1. Old field/endpoint deprecated deb belgilanadi
2. Documentation’da yoziladi
3. Clientlarga xabar beriladi
4. Metrics bilan usage o‘lchanadi
5. Migration deadline beriladi
6. Deadline’dan keyin olib tashlanadi

Masalan:

Deprecation: true
Sunset: Wed, 31 Dec 2026 23:59:59 GMT

26. Contract testing

Migration’da contract test juda foydali.

Maqsad:

Provider o‘zgarsa ham consumer buzilmasin

Masalan:

order-service API response o‘zgardi
mobile app yoki payment-service buzilmasligi kerak

Contract test tools:

Spring Cloud Contract
Pact
OpenAPI diff tools
consumer-driven contract tests

27. Database migration strategy

Database migration ham upgrade strategy’ning bir qismi.

Qoida:

Database migration backward compatible bo‘lishi kerak.

Yomon:

ALTER TABLE users DROP COLUMN username;

Bu eski applicationni buzadi.

Yaxshi expand-contract pattern:

1. Expand: yangi column qo‘shish
2. App eski va yangi column bilan ishlaydi
3. Backfill data
4. Client/app yangi columnga o‘tadi
5. Contract: eski columnni keyin olib tashlash

Expand-contract misol

1. Yangi column:

ALTER TABLE users ADD COLUMN full_name VARCHAR(255);

2. App ikkala fieldni yozadi:

username + full_name

3. Backfill:

UPDATE users SET full_name = username WHERE full_name IS NULL;

4. App faqat full_name o‘qiydi.

5. Keyingi release’da:

ALTER TABLE users DROP COLUMN username;

28. Rollout strategy

Upgrade production’da birdan hamma userga berilmasligi kerak.

Variantlar:

blue-green deployment
canary deployment
rolling deployment
feature flags
dark launch
shadow traffic

Canary

1% traffic → new version
5% traffic → new version
25% traffic → new version
100% traffic → new version

Bu vaqt davomida kuzatiladi:

error rate
latency
CPU/memory
database query time
business metrics
security failures

29. Rollback strategy

Migration’dan oldin rollback aniq bo‘lishi kerak.

Savollar:

old app new database schema bilan ishlaydimi?
migration reversiblemi?
data o‘zgargan bo‘lsa rollback qanday?
message format backward compatiblemi?
clientlar eski API’ga qayta oladimi?

Eng yomon holat:

new app deploy qilindi
database destructive migration qildi
app yiqildi
old app schema bilan ishlamaydi
rollback imkonsiz

Shuning uchun database migration expand-contract bo‘lishi kerak.

30. Observability during migration

Migration monitoring’siz qilinmaydi.

Kerakli dashboard:

startup errors
HTTP 4xx/5xx
p95/p99 latency
DB connection pool
slow queries
Kafka consumer lag
memory/GC
security denied requests
business KPI

Loglarda migration flag foydali:

{
  "service": "order-service",
  "version": "3.0.0-migration",
  "springBoot": "3.5.x",
  "traceId": "abc123",
  "message": "Order created"
}

31. Spring Boot 2 → 3 migration checklist

Java 17+ ga o‘tildi
Spring Boot latest 2.7.x ga ko‘tarildi
Deprecated API’lar tozalandi
javax.* importlar jakarta.* ga o‘tdi
Spring Security config yangilandi
Hibernate queries test qilindi
Validation imports yangilandi
Servlet filters yangilandi
OpenAPI/generated code yangilandi
Third-party libraries Boot 3 compatible
Actuator endpoints tekshirildi
Metrics/tracing tekshirildi
Integration tests o‘tdi
Performance baseline solishtirildi
Canary deploy qilindi
Rollback plan bor

32. Real migration example

Tasavvur qilamiz:

order-service
Java 11
Spring Boot 2.5
Spring Security old config
Hibernate 5
javax.persistence

To‘g‘ri migration:

Step 1: Java 17 support qo‘shish
Step 2: Spring Boot 2.7.x ga o‘tish
Step 3: Security 5.8 style configga o‘tish
Step 4: Deprecated configlarni tozalash
Step 5: javax → jakarta migration
Step 6: Boot 3 ga o‘tish
Step 7: Hibernate querylarni tuzatish
Step 8: Testcontainers bilan DB test
Step 9: Canary deploy
Step 10: full rollout

33. Eng ko‘p xatolar

Xato 1: Big bang upgrade

Java 11 → 21
Boot 2.4 → 3.5
Security 5 → 6
Hibernate 5 → 6
hammasi bitta PR’da

Bu xavfli.

Xato 2: Compile bo‘lsa yetadi deb o‘ylash

Migration’da runtime behavior muhim:

security rules
transaction behavior
serialization
query behavior
cache behavior
metrics/tracing

Xato 3: Database rollback o‘ylanmagan

Destructive migration rollbackni o‘ldiradi.

Xato 4: Third-party dependency tekshirilmagan

Eski SDK javax.* ishlatsa, Boot 3'da muammo beradi.

Xato 5: API compatibility buzilgan

Backend upgrade bo‘ldi, lekin mobile app eski response kutyapti.

34. Arxitektor xulosasi

Migration & upgrade strategy - bu production systemni yangilashda xavfni kamaytirish san’ati.

Asosiy qoida:

Upgrade step-by-step qilinadi.
Breaking change oldindan aniqlanadi.
API backward compatibility saqlanadi.
Database migration expand-contract bo‘ladi.
Dependency/CVE markazdan boshqariladi.
Rollout canary/blue-green bilan qilinadi.
Rollback oldindan tayyor bo‘ladi.

Spring Boot 2 → 3 uchun qisqa formula:

Latest 2.7.x
+ Java 17+
+ javax → jakarta
+ Security 6 migration
+ Hibernate 6 validation
+ dependency compatibility
+ full regression
+ canary rollout
= xavfsiz Spring Boot 3 migration