Migrating a Large‑Scale SaaS Service to a Single Server: Architecture, Challenges, and Solutions

This article describes the technical practice of moving a SaaS platform serving hundreds of thousands of users from a public‑cloud micro‑service architecture to a single on‑premise server using the Tencent Cloud WeDa low‑code platform.

Background : Enterprises often need to deploy software in a localized environment for compliance, security, or budget reasons. The challenge is to run a complex SaaS system on a single machine while preserving functionality and performance.

What is WeDa? WeDa is a high‑performance low‑code development platform that provides both a design‑time workspace for building applications and a runtime base for deploying them. It supports multi‑terminal output (PC, H5, mini‑programs), connects to local and external databases, integrates AI models, and can be packaged for private deployment with a single command.

Migration Practice :

1. Product Form – The platform consists of a design side (application workspace) and a runtime side (deployment base).

2. Technical Architecture – The hybrid‑cloud architecture includes basic services, gateway services, service control (30+ micro‑services), and supporting components such as MySQL, MongoDB, Redis, Kafka, and object storage.

3. Key Challenges:

How to support both distributed micro‑services (public cloud) and a monolithic deployment (private server) given limited hardware.

Keeping private‑deployment code synchronized with rapid public‑cloud updates.

Solution Overview :

• Service Merging : Each micro‑service can be compiled as an independent process (“splittable”) or merged as a module into a single Spring Boot application (“combinable”). This reduces 30+ processes to a single process.

• Bean Conflict Resolution : Rename packages by domain, add domain prefixes to bean names, and adjust @ComponentScan exclusions.

• Feign + Consul Refactor : Replace Consul‑based service discovery with localhost URLs for the monolithic deployment.

• pom.xml Refactor : Add a private Maven profile, disable the Spring Boot plugin, and exclude resource files that are now unified.

@EnableFeignClients
@ComponentScan(basePackages = {"com.tencent.weda"}, excludeFilters = {@ComponentScan.Filter(type = FilterType.ASSIGNABLE_TYPE, classes = {com.tencent.weda.WeDaBusinessApplication.class, com.tencent.weda.ServerApplication.class, /* ... */})
@SpringBootApplication
public class WedaApplication {
public static void main(String[] args) {
SpringApplication.run(WedaApplication.class, args);
}
}

Build command for the private profile:

mvn clean install -DskipTests -P$SPRING_PROFILE -s ../settings.xml

• Configuration Refactor : Consolidate all micro‑service YAML files into a single namespace (e.g., weda.model.xxx , weda.auth.xxx , weda.connector.xxx ) to avoid key collisions.

• Database Sync : A side‑car service periodically scans public‑cloud DB DDL/DML changes and packages them into the private deployment.

• Automated Testing : After merging, a CI pipeline builds the monolithic package, deploys it, and runs automated tests to catch bean or configuration conflicts early.

Results :

• Architecture dimension – Micro‑service count reduced from >30 to single‑digit.

• Resource dimension – The new architecture runs on a single 8C 16G server, dramatically lowering hardware costs.

• Delivery – Suitable for customers with limited IDC budget, private‑deployment needs, multi‑platform (mini‑program, web, H5) requirements, or integration with enterprise tools.

Conclusion : The migration demonstrates that a large‑scale SaaS can be efficiently run on a single server by merging services, refactoring beans and configurations, and automating synchronization. While monolithic deployment simplifies operations and reduces cost, the choice between micro‑service and monolithic architectures should be driven by specific business scenarios.