Skip to main content
Nguyễn Văn Lạc Thiên
💬
0 discussions

Saas Migration Process

I. Benefits​

  • Quy trình cho việc di dời hệ thống cơ bản của một sản phẩm Saas
  • Thay đổi hệ thống server để đảm bảo độ nhanh và bảo mật hệ thống
  • Tăng tính sẵn sàng khi có vấn đề server

II. Prerequisites​

  • Có tài khoản truy cập các tài nguyên trên hệ thống với đầy đủ quyền chỉnh sửa, xóa
  • Có hiểu biết cơ bản về các nơi liên quan cần điều chỉnh khi thay đổi server

III. Infomation Level​

  • infoLevel:3 (reader must be signed official employee's contract from at least junior grade)
  • writingLevel:1 (only text without image/video)

IV. Main content:​

Quy trình Migration hệ thống SaaS từ Server cũ sang Server mới

Khi một sản phẩm SaaS phát triển, việc thay đổi server là điều khó tránh khỏi. Server có thể không còn đủ CPU, RAM hoặc dung lượng lưu trữ; doanh nghiệp cũng có thể cần chuyển sang hạ tầng mới để tăng hiệu năng, khả năng mở rộng hoặc nâng cao độ an toàn.

Tuy nhiên, migration không đơn giản là tạo một server mới rồi copy code sang.

Một hệ thống SaaS thường bao gồm nhiều thành phần liên kết với nhau:

                         Người dùng
                             │
                             ▼
                    ┌────────────────┐
                    │ Domain / DNS   │
                    └───────┬────────┘
                            ▼
                    ┌────────────────┐
                    │ Load Balancer  │
                    └───────┬────────┘
                            ▼
                    ┌────────────────┐
                    │ Application    │
                    │ Server         │
                    └───────┬────────┘
                            │
              ┌─────────────┼─────────────┐
              ▼             ▼             ▼
          Database        Cache       File Storage

Nếu chỉ di chuyển phần Application Server mà quên Database, firewall, authentication, DNS, storage hoặc các dịch vụ phụ thuộc, server mới có thể chạy được nhưng hệ thống vẫn không hoạt động đúng.

Vì vậy, migration nên được hiểu là:

Di chuyển toàn bộ môi trường cần thiết để hệ thống có thể hoạt động từ hạ tầng cũ sang hạ tầng mới, sau đó chuyển traffic sang môi trường mới một cách có kiểm soát.

1. Mục tiêu của Migration

Một quy trình migration tốt thường hướng tới các mục tiêu:

  • Đưa hệ thống sang server mới mà không làm gián đoạn dịch vụ hoặc giảm downtime xuống mức thấp nhất.
  • Giữ nguyên chức năng của hệ thống sau khi chuyển đổi.
  • Đảm bảo server mới có cấu hình phù hợp với hệ thống hiện tại.
  • Đảm bảo server mới kết nối được với các dịch vụ phụ thuộc.
  • Chuẩn hóa cấu hình bảo mật và vận hành.
  • Có khả năng quay lại server cũ nếu migration thất bại.
  • Có đầy đủ bước kiểm tra trước và sau khi chuyển traffic.

Điểm quan trọng nhất là:

Không nên xem migration là một lần "copy server". Đây là quá trình chuyển đổi có kiểm soát từ môi trường cũ sang môi trường mới.

2. Tổng quan quy trình

Một quy trình migration SaaS có thể chia thành 8 giai đoạn:

1. Khảo sát hệ thống hiện tại
          ↓
2. Lập kế hoạch Migration
          ↓
3. Chuẩn bị Server mới
          ↓
4. Thiết lập môi trường
          ↓
5. Di chuyển Code / Configuration / Data
          ↓
6. Kiểm thử trên Server mới
          ↓
7. Chuyển Traffic
          ↓
8. Monitoring & Hoàn tất

Mỗi giai đoạn có mục đích khác nhau.

Đặc biệt, chuyển traffic chỉ nên thực hiện sau khi server mới đã được kiểm thử.

3. Bước 1 — Khảo sát hệ thống hiện tại

Trước khi tạo server mới, cần hiểu server cũ đang chạy những gì.

Đây là bước thường bị bỏ qua nhất nhưng lại có ảnh hưởng lớn nhất đến kết quả migration.

3.1. Xác định các thành phần của hệ thống​

Lập danh sách tất cả thành phần đang chạy.

Ví dụ:

Thành phầnVai trò
ApplicationChạy logic của sản phẩm
DatabaseLưu dữ liệu
CacheLưu dữ liệu tạm thời
AuthenticationĐăng nhập và quản lý tài khoản
Reverse ProxyNhận và chuyển request
Load BalancerPhân phối traffic
File StorageLưu file
MonitoringTheo dõi hệ thống
LoggingLưu log
Background JobsChạy các tác vụ nền
External ServicesDịch vụ bên ngoài

Không nhất thiết hệ thống nào cũng có tất cả thành phần trên.

Điều quan trọng là phải biết:

Server cũ đang phụ thuộc vào những gì?

3.2. Kiểm tra cấu hình hiện tại​

Thu thập các thông tin:

  • CPU.
  • RAM.
  • Disk.
  • Network.
  • Operating System.
  • IP.
  • Port.
  • Domain.
  • SSL.
  • Container.
  • Service.
  • Environment variables.
  • Cron jobs.
  • Scheduled tasks.
  • Firewall.
  • SSH configuration.
  • Các service chạy nền.

Nếu sử dụng container, cần xác định:

  • Container nào đang chạy.
  • Image nào đang sử dụng.
  • Volume nào được mount.
  • Network nào được sử dụng.
  • Port nào được expose.
  • File cấu hình nằm ở đâu.

3.3. Xác định dependency​

Một application thường không hoạt động độc lập.

Ví dụ:

Application
    │
    ├── Database
    ├── Redis
    ├── Authentication
    ├── Object Storage
    ├── Email Service
    ├── Payment Service
    └── Third-party API

Cần lập danh sách các dependency này để đảm bảo server mới có thể kết nối đến chúng.

4. Bước 2 — Lập kế hoạch Migration

Sau khi hiểu hệ thống, cần xác định migration sẽ được thực hiện như thế nào.

Một kế hoạch cơ bản nên trả lời:

Khi nào migration?​

Chọn thời điểm có lượng người dùng thấp nếu có thể.

Ai thực hiện?​

Xác định người phụ trách:

  • Infrastructure.
  • Application.
  • Database.
  • Network.
  • Người kiểm thử.

Chuyển cái gì?​

Xác định rõ phạm vi:

  • Code.
  • Configuration.
  • Container.
  • File.
  • Database.
  • Certificate.
  • Network.
  • Scheduled jobs.

Cái gì không chuyển?​

Ví dụ Database có thể tiếp tục sử dụng hệ thống hiện tại thay vì di chuyển cùng server application.

Điều này rất quan trọng vì:

Migration server không đồng nghĩa với migration toàn bộ hệ thống.

5. Bước 3 — Chuẩn bị Server mới

Sau khi có kế hoạch, tạo server mới với tài nguyên phù hợp.

Có thể chọn:

  • Tạo server mới hoàn toàn.
  • Clone template.
  • Clone server hiện tại.
  • Dùng Infrastructure as Code để tạo lại môi trường.

Cần xác định:

  • CPU.
  • RAM.
  • Storage.
  • Network.
  • Region.
  • Operating System.

Đặt tên server​

Nên sử dụng quy ước nhất quán.

Ví dụ:

prod-app-01
prod-app-02
staging-app-01
dev-app-01

Tên nên thể hiện:

Môi trường + vai trò + số thứ tự

6. Bước 4 — Chuẩn bị quyền truy cập

Trước khi triển khai application, cần đảm bảo server mới có phương thức truy cập an toàn.

6.1. SSH​

Khuyến nghị:

  • Sử dụng SSH Key.
  • Không sử dụng password nếu không cần thiết.
  • Không cho phép đăng nhập root trực tiếp.
  • Chỉ cấp quyền quản trị cho những tài khoản cần thiết.

Có thể sử dụng:

Administrator
      │
      ▼
SSH Key
      │
      ▼
Server mới

6.2. Firewall​

Chỉ mở những port thực sự cần thiết.

Ví dụ:

Internet
   │
   ├── 80   → HTTP
   ├── 443  → HTTPS
   │
   └── SSH  → Quản trị

Không nên mở toàn bộ port chỉ để "cho dễ triển khai".

7. Bước 5 — Cho phép Server mới kết nối Database

Đây là một trong những bước quan trọng nhất.

Nếu Database có firewall hoặc IP whitelist, server mới phải được cấp quyền truy cập.

Ví dụ:

                Database
                    ▲
                    │
             Allowed IPs
                    │
          ┌─────────┴─────────┐
          │                   │
     Server cũ           Server mới
       ✓                      ✓

Cần kiểm tra:

  • Database có whitelist IP không?
  • Database có firewall không?
  • Có private network không?
  • Có VPN không?
  • Có security group không?
  • Có TLS/certificate không?

Không nên chỉ kiểm tra "ping được"​

Server có thể ping được Database nhưng application vẫn không kết nối được.

Cần kiểm tra cả:

  • Network.
  • Port.
  • Authentication.
  • TLS.
  • Database credentials.
  • Application-level connection.

8. Bước 6 — Cài đặt môi trường trên Server mới

Bây giờ bắt đầu đưa server mới về trạng thái tương đương server cũ.

8.1. Cập nhật hệ điều hành​

Thực hiện cập nhật các package và security update cần thiết.

Sau đó cài những công cụ cơ bản phục vụ vận hành:

Git
Curl
Wget
Unzip
Monitoring tools
Network tools
Build tools

Không nên cài mọi thứ một cách tùy tiện.

Chỉ cài những thành phần hệ thống thực sự cần thiết.

8.2. Cấu hình Timezone và thời gian​

Đảm bảo server có timezone và đồng bộ thời gian chính xác.

Điều này quan trọng đối với:

  • Log.
  • Token.
  • Certificate.
  • Scheduled jobs.
  • Database timestamp.
  • Monitoring.

8.3. Cấu hình bảo mật​

Thiết lập:

  • Firewall.
  • SSH.
  • Fail2ban nếu cần.
  • Automatic security updates.
  • User permission.
  • File permission.
  • Log rotation.

Mục tiêu là server mới không chỉ "chạy được" mà còn an toàn để đưa vào production.

9. Bước 7 — Triển khai Application Runtime

Tùy kiến trúc, application có thể chạy bằng:

  • Docker.
  • Kubernetes.
  • PM2.
  • Systemd.
  • Java service.
  • Python service.
  • Node.js service.
  • Các runtime khác.

Nguyên tắc chung là:

Môi trường mới phải tương thích với môi trường đang chạy production.

Nếu server cũ chạy:

Node.js 18
Python 3.11
Docker version X

thì không nên tự ý sử dụng phiên bản hoàn toàn khác trên server mới nếu chưa kiểm tra compatibility.

10. Bước 8 — Di chuyển Code và Configuration

Đưa source code hoặc container image lên server mới.

Có thể lấy code từ:

  • Git repository.
  • Container registry.
  • Artifact repository.
  • Build pipeline.

Không nên copy toàn bộ server một cách mù quáng​

Cần phân biệt:

Source Code
Configuration
Secret
Generated Data
Temporary Files
Cache
Log

Không phải tất cả đều nên được copy.

Ví dụ:

Server cũ
│
├── Application Code       → Copy
├── Configuration          → Recreate / Copy
├── Secrets                → Quản lý an toàn
├── Cache                  → Không nhất thiết copy
├── Temporary files        → Không cần copy
└── Logs                   → Thường không cần copy

11. Bước 9 — Quản lý Configuration và Secret

Một lỗi phổ biến khi migration là:

Code đã chạy nhưng application không kết nối được Database.

Nguyên nhân thường nằm ở configuration.

Cần kiểm tra:

  • Database URL.
  • Redis URL.
  • API key.
  • Secret key.
  • Authentication configuration.
  • Storage configuration.
  • Third-party credentials.
  • Environment variables.

Nguyên tắc​

Không nên hard-code secret vào source code.

Nên sử dụng:

  • Secret manager.
  • Environment variables.
  • Encrypted configuration.
  • Platform secret storage.

12. Bước 10 — Triển khai các dịch vụ phụ thuộc

Nếu application phụ thuộc vào các service khác, cần triển khai hoặc kết nối chúng theo đúng thứ tự.

Ví dụ:

Network
   ↓
Reverse Proxy
   ↓
Authentication
   ↓
Application
   ↓
Database / Cache

Thứ tự thực tế phụ thuộc vào kiến trúc.

Sau mỗi service, nên kiểm tra:

Service started?
      ↓
Port available?
      ↓
Configuration correct?
      ↓
Dependency reachable?
      ↓
Logs normal?

Không nên khởi động toàn bộ hệ thống rồi mới bắt đầu tìm lỗi.

13. Bước 11 — Kiểm tra Server mới trước khi nhận Traffic

Đây là giai đoạn cực kỳ quan trọng.

Server mới chưa cần nhận traffic production ngay.

Trước tiên, hãy kiểm tra nội bộ.

Kiểm tra Infrastructure​

  • CPU.
  • RAM.
  • Disk.
  • Network.
  • Container.
  • Service.
  • Port.

Kiểm tra Application​

  • Application có khởi động không?
  • Có restart liên tục không?
  • Có error trong log không?
  • Có kết nối được Database không?
  • Có kết nối được Cache không?

Ví dụ:

Application
    │
    ├── Database ✓
    ├── Cache ✓
    ├── Authentication ✓
    ├── Storage ✓
    └── External API ✓

Chỉ khi các dependency quan trọng đều hoạt động mới chuyển sang bước tiếp theo.

14. Bước 12 — Kiểm thử chức năng

Không nên chỉ kiểm tra:

"Server trả HTTP 200."

Cần kiểm tra những chức năng người dùng thực sự sử dụng.

Ví dụ​

Authentication​

  • Đăng nhập.
  • Đăng xuất.
  • Refresh session.
  • Phân quyền.

Application​

  • Truy cập giao diện.
  • Tạo dữ liệu.
  • Sửa dữ liệu.
  • Xóa dữ liệu.
  • Tìm kiếm.

Integration​

  • Gửi request đến hệ thống bên ngoài.
  • Nhận webhook.
  • Đồng bộ dữ liệu.

Background Jobs​

  • Scheduled jobs.
  • Queue.
  • Worker.

Communication​

Nếu sản phẩm có voice/chat:

  • Kết nối.
  • Gửi/nhận.
  • Logging.
  • Recording.

15. Bước 13 — Đưa Server mới vào Load Balancer

Sau khi server mới vượt qua kiểm thử, mới cho phép nó nhận traffic.

Có thể thực hiện theo hai cách.

Cách 1: Chuyển toàn bộ traffic​

Trước:

Users
  │
  ▼
Load Balancer
  │
  ▼
Server cũ

Sau:

Users
  │
  ▼
Load Balancer
  │
  ▼
Server mới

Cách 2: Chuyển từng phần traffic​

Đây thường là cách an toàn hơn.

             Load Balancer
                  │
          ┌───────┴───────┐
          ▼               ▼
     Server cũ        Server mới
       90%                10%

Sau khi kiểm tra ổn định:

     50%                50%

Sau đó:

     10%                90%

Cuối cùng:

      0%               100%

Cách này giúp phát hiện lỗi trước khi toàn bộ người dùng bị ảnh hưởng.

16. Bước 14 — Monitoring sau khi chuyển Traffic

Migration chưa kết thúc ngay sau khi Load Balancer chuyển sang server mới.

Cần theo dõi hệ thống trong một khoảng thời gian.

Theo dõi:

  • CPU.
  • RAM.
  • Disk.
  • Network.
  • Error rate.
  • Response time.
  • Application logs.
  • Database errors.
  • Container restart.
  • Authentication errors.
  • Background jobs.

Đặc biệt cần so sánh:

Server cũ
    ↕
Các chỉ số trước migration
    ↕
Server mới
    ↓
Các chỉ số sau migration

Nếu server mới có lượng error tăng bất thường, cần điều tra ngay.

17. Bước 15 — Chuẩn bị Rollback

Một migration tốt luôn phải có câu trả lời cho câu hỏi:

"Nếu server mới lỗi thì làm sao quay lại?"

Ví dụ:

                Load Balancer
                     │
              ┌──────┴──────┐
              ▼             ▼
         Server cũ      Server mới
         (Backup)        (Primary)
                            │
                         ERROR
                            │
                            ▼
                    Quay traffic
                    về Server cũ

Server cũ không nên bị xóa ngay sau khi migration thành công.

Nên giữ lại trong một khoảng thời gian phù hợp để có thể rollback nếu phát hiện lỗi muộn.

18. Bước 16 — Hoàn tất Migration

Chỉ xác nhận migration hoàn tất khi:

  • Server mới hoạt động ổn định.
  • Application hoạt động bình thường.
  • Database kết nối bình thường.
  • Authentication hoạt động.
  • Các integration hoạt động.
  • Monitoring không phát hiện vấn đề nghiêm trọng.
  • Traffic đã chuyển sang server mới.
  • Không còn request quan trọng đi qua server cũ.
  • Rollback plan đã được đánh giá.

Sau đó mới cân nhắc:

  • Xóa server cũ.
  • Thu hồi IP.
  • Thu hồi quyền truy cập.
  • Xóa resource không còn sử dụng.
  • Cập nhật tài liệu hệ thống.

19. Các lỗi thường gặp

Lỗi 1: Server chạy nhưng không kết nối được Database​

Nguyên nhân thường gặp​

  • IP chưa được whitelist.
  • Firewall chặn.
  • Sai port.
  • Sai credential.
  • Sai hostname.
  • Sai TLS configuration.

Cách xử lý​

Kiểm tra theo thứ tự:

Network
   ↓
Port
   ↓
Authentication
   ↓
TLS
   ↓
Application

Lỗi 2: Container liên tục restart​

Nguyên nhân​

Application khởi động nhưng gặp lỗi dependency.

Ví dụ:

Application
    ↓
Connect Database
    ↓
Connection Failed
    ↓
Process Exit
    ↓
Container Restart

Cách xử lý​

Kiểm tra log application trước, sau đó kiểm tra dependency.

Không nên chỉ restart container nhiều lần mà không tìm nguyên nhân.

Lỗi 3: Server mới truy cập được nhưng người dùng không truy cập được​

Nguyên nhân​

Có thể nằm ở:

  • DNS.
  • Load Balancer.
  • Reverse Proxy.
  • Firewall.
  • SSL.
  • Routing.

Điều này cho thấy:

Application chạy được không có nghĩa là hệ thống đã migration thành công.

Lỗi 4: Cấu hình bị thay đổi trực tiếp trong container​

Một lỗi phổ biến khi sử dụng container là sửa file trực tiếp bên trong container.

Khi container được tạo lại, thay đổi đó có thể mất.

Nên quản lý configuration bên ngoài:

Host
 │
 ├── Configuration
 ├── Secret
 └── Certificate
       │
       ▼
    Container

Nhờ vậy, việc triển khai lại container không làm mất cấu hình.

Lỗi 5: Chuyển traffic quá sớm​

Nếu server mới chưa được kiểm thử mà đã đưa toàn bộ traffic vào, một lỗi nhỏ có thể ảnh hưởng đến toàn bộ người dùng.

Do đó nên:

Test trước → Canary nếu có thể → Chuyển traffic → Monitor → Hoàn tất.

20. Checklist Migration

Trước Migration​

  • Xác định phạm vi migration
  • Khảo sát server hiện tại
  • Liệt kê application
  • Liệt kê database
  • Liệt kê service phụ thuộc
  • Kiểm tra network
  • Kiểm tra domain/DNS
  • Kiểm tra Load Balancer
  • Kiểm tra SSL
  • Kiểm tra backup
  • Chuẩn bị rollback plan

Chuẩn bị Server mới​

  • Tạo server
  • Cấu hình CPU/RAM/Storage
  • Cấu hình network
  • Thiết lập SSH Key
  • Tạo user quản trị
  • Cấu hình firewall
  • Cấu hình SSH security
  • Cài runtime/container platform
  • Cài monitoring
  • Cài logging

Triển khai​

  • Deploy source code/image
  • Deploy configuration
  • Cấu hình secrets
  • Kết nối Database
  • Kết nối Cache
  • Kết nối Storage
  • Kết nối Authentication
  • Deploy reverse proxy
  • Deploy background jobs
  • Kiểm tra logs

Kiểm thử​

  • Application khởi động bình thường
  • Container không restart liên tục
  • Database connection
  • Cache connection
  • Authentication
  • API
  • Web application
  • Integration
  • Background jobs
  • Các chức năng nghiệp vụ quan trọng

Chuyển Traffic​

  • Đưa server mới vào Load Balancer
  • Kiểm tra health check
  • Chuyển một phần traffic nếu có thể
  • Theo dõi lỗi
  • Chuyển toàn bộ traffic
  • Xác nhận traffic đã vào server mới

Sau Migration​

  • Monitoring server mới
  • Kiểm tra application logs
  • Kiểm tra Database
  • Kiểm tra error rate
  • Kiểm tra performance
  • Kiểm tra background jobs
  • Xác nhận hệ thống ổn định
  • Giữ server cũ trong thời gian dự phòng
  • Ghi nhận kết quả migration
  • Thu hồi server cũ khi đủ điều kiện

21. Sơ đồ tổng thể của một lần Migration

Có thể minh họa quy trình bằng sơ đồ:

SaaS Migration Process 1

22. Một hình khác: Server cũ và Server mới

Có thể sử dụng một sơ đồ đơn giản hơn để giải thích bản chất của migration:

SaaS Migration Process 2

23. Nguyên tắc quan trọng nhất

Có thể tóm tắt toàn bộ quy trình migration bằng một nguyên tắc:

Đừng chuyển traffic sang một server mà bạn chưa chứng minh được rằng nó có thể thay thế server cũ.

Một migration an toàn thường có ba trạng thái:

OLD SERVER
    │
    │  Chuẩn bị & kiểm thử
    ▼
NEW SERVER
    │
    │  Chuyển traffic
    ▼
NEW SERVER = PRIMARY
OLD SERVER = BACKUP

Chỉ sau khi server mới hoạt động ổn định trong khoảng thời gian phù hợp mới nên loại bỏ server cũ.

Kết luận

Migration một hệ thống SaaS không chỉ là việc chuyển code từ máy chủ này sang máy chủ khác. Đây là quá trình tái tạo môi trường, kết nối lại các thành phần phụ thuộc, kiểm thử và chuyển quyền xử lý traffic từ hệ thống cũ sang hệ thống mới.

Một quy trình migration đáng tin cậy nên luôn đi theo trình tự:

Khảo sát → Lập kế hoạch → Chuẩn bị → Cấu hình → Deploy → Kiểm thử → Chuyển Traffic → Monitoring → Rollback nếu cần → Hoàn tất.

Trong đó, ba nguyên tắc quan trọng nhất là:

  1. Biết rõ hệ thống cũ đang phụ thuộc vào những gì trước khi di chuyển.
  2. Kiểm thử server mới trước khi cho người dùng truy cập.
  3. Luôn giữ một phương án rollback trước khi chuyển traffic.

Nếu thực hiện đúng ba nguyên tắc này, migration sẽ chuyển từ một hoạt động "thử và hy vọng hệ thống chạy" thành một quy trình có kiểm soát, có thể lặp lại và áp dụng cho nhiều hệ thống SaaS khác nhau.

Nếu bạn đang tìm một giải pháp tổng đài SIP có khả năng tích hợp CRM, quản lý cuộc gọi và mở rộng theo mô hình SaaS, bạn có thể bắt đầu bằng việc trải nghiệm demo thực tế trước khi triển khai toàn hệ thống.
Đăng ký dùng thử hệ thống tổng đài miễn phí tại đây: Đăng ký ngay!

V. Read more:​