How an open-source skill set turns "we don't know what we have" into a system diagram, a migration plan, and a validated Function Compute package.
Most articles about cloud migration start at the interesting part: rewriting API calls, tuning inference, redesigning a data pipeline. In real projects, that part is rarely where the schedule dies.
The schedule dies earlier.
Here is a pattern that anyone who has worked on enterprise migration will recognize.
A company builds an application. Over the years, the engineers who built it move on, or the team shrinks to one part-time maintainer. The system keeps running, so nobody touches it. It quietly becomes legacy — not because the technology is old, but because the knowledge about it is gone.
Then something forces a move. Infrastructure cost has to come down. The business wants to enter the China market and needs a presence in-region. A contract renewal, a compliance requirement, a data residency rule. Migration becomes mandatory.
So the company calls a system integrator, or a cloud vendor's solution architect, and asks for a proposal. And the conversation goes like this:
SA: What does the current system look like?
Customer: ...we're not entirely sure. There's a web app, a database, and some AI part.
SA: Which services does it call? What are the dependencies? Where is data stored?
Customer: We'd have to check.
Nobody can answer, so nobody can scope. And because the customer cannot describe the system concretely, they also cannot define what would be shared under an NDA — which means they cannot even ask the vendor to investigate it for them. The engagement cannot start, because the input the engagement needs is the output the engagement was supposed to produce.
The project stalls. Sometimes for a quarter. Sometimes for a year.
The bottleneck is not the rewrite. The bottleneck is the assessment phase, and specifically the very first step: producing a shareable, accurate picture of what you actually have.
CloudPort Agent is an open-source (Apache-2.0) set of native Qwen Code Agent Skills built around that observation. It does perform the migration — but it starts by drawing the map.
The system-diagram-generator skill takes a repository and produces a single self-contained HTML architecture report. It is deliberately standalone: it is not part of the migration execution path, and you can use it on any repository you want to understand, whether or not you ever migrate it.
The full procedure is four steps.
1. Install Qwen Code.
bash -c "$(curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen.sh)" -s --source bailianOn macOS with Homebrew, this route also works and is what was used for the runs described here:
brew install node@22
brew link --overwrite node@22
brew install qwen-codeEither way, authenticate against Alibaba Cloud Model Studio with /auth once Qwen Code starts.
2. Put the CloudPort skills where Qwen Code will find them.
git clone https://github.com/webbigdata-jp/cloudport-agent.git
mkdir -p ~/.qwen/skills
cp -R cloudport-agent/skills/. ~/.qwen/skills/(Or copy them into a single project as .qwen/skills/ if you prefer to scope them per repository.)
3. Clone the repository you want to understand.
git clone https://github.com/your-org/the-system-nobody-remembers.git
cd the-system-nobody-remembers4. Ask.
qwen
> Please draw a system overview diagram of this repository.The agent reads the repository — source files, dependency manifests, configuration, infrastructure definitions, deployment scripts — and writes an HTML report you can open in a browser and email to anyone.
A generated sample is included in the repository(examples/system-diagram-generator-output
/):
That artifact is the thing that unblocks the conversation. Hand it to an SI partner or a cloud architect and they can finally do their job: estimate scope, size the effort, identify the risky parts, and propose an architecture. What used to be a months-long game of archaeology becomes an attachment.
The report is written to be confidentiality-safe. The skill instructs the agent to describe structure, components, and dependencies, and to leave out credentials, secrets, and business-specific proper nouns. precisely because the artifact's purpose is to be shared outside the company before an NDA is in place.
Two honest caveats belong here.
The output is a draft, not an audit. This is LLM-generated, so someone on the customer side must read the report once before it leaves the building — both to correct anything inaccurate and to confirm nothing sensitive slipped through. That review takes an afternoon. The alternative takes a quarter.
Reviewing a repository means sending parts of it to an inference endpoint. That is worth stating plainly rather than glossing over, because it is exactly the objection a security team will raise. Three things are worth knowing:
That flexibility matters more than it might seem. The organizations most likely to have lost track of their own architecture are frequently the same ones with the strictest rules about what may be transmitted. A discovery tool that only works in one trust configuration would be useless to exactly the people who need it most.
Once the picture exists, the rest of CloudPort Agent takes over. Point Qwen Code at a repository containing an existing AI application and the workflow runs:
The skills that make this up:
| Skill | Role |
|---|---|
system-diagram-generator |
Standalone discovery / handover report |
project-profile-generator |
Scans an unfamiliar repository and writes a thin project profile |
gemini-to-qwen-api-mapping |
Maps existing SDK, REST, and provider-config usage to Model Studio–compatible patterns, including multimodal and structured output |
dependency-migration |
Updates dependency files, lockfiles, imports, and environment variables without disturbing unrelated packages |
migration-validation |
Equivalence checks, schema checks, vector-index compatibility, smoke-run sign-off |
deploy-alibaba-fc-advisor |
Builds and validates the Function Compute artifact, then produces a human-executed deployment checklist |
Inside the checked-out repository, CloudPort Agent is autonomous: it investigates, edits, migrates dependencies, runs tests, repairs failures, and validates the deployment package. Qwen Code's approval system remains the local safety layer, blocking or escalating commands it classifies as destructive.
Outside the repository, the boundary is deliberate. Creating cloud resources, supplying production credentials, rebuilding a billable vector index, and deploying to production all change either spend or availability. CloudPort prepares the artifact and the exact commands; a human runs them.
This is not a limitation so much as a reflection of how migration projects actually work. Advisors advise; the customer's own team or their SI partner executes. A tool that fits that split — thorough preparation, human-owned execution — is a tool that can be adopted without a governance argument.
"It migrated" is easy to claim and hard to believe. The repository therefore ships a complete, runnable example rather than a description of one:
examples/gemini-streamlit-cloudrun-to-qwen-fc/
It is a Streamlit application, originally written against another provider's SDK and serverless container platform, migrated to Alibaba Cloud Model Studio and Function Compute. The point of choosing this particular application is coverage: it exercises text generation, image understanding, and video understanding — the three modalities that migration efforts most often quietly drop, because the text path is easy and the multimodal paths are where request shapes diverge.
| File | What it demonstrates |
|---|---|
cloudport_compat.py |
The compatibility layer: request/response mapping onto the Model Studio API, including multimodal payloads |
app.py |
The migrated application itself |
tests/test_cloudport_compat.py |
Offline request-mapping and safety tests — no API key needed |
smoke_test.py |
Live checks against the real API for text, image, and video |
deploy.sh |
Builds a self-contained Function Compute ZIP |
README.md |
Build and verification instructions |
The two-tier verification is the part worth stealing even if you never use CloudPort. Offline tests assert that requests are shaped correctly and run in CI for free; the live smoke test asserts that each modality actually returns a sane answer from the deployed configuration. "Deployment succeeded" and "the application works" are different claims, and only the second one matters.
A note on deploy.sh: the Function Compute 3.0 Custom Runtime does not guarantee a package manager or arbitrary language runtimes on PATH, so anything that installs dependencies at cold start is a trap. The artifact must be self-contained, with dependencies vendored at build time. CloudPort's deployment skill encodes that rule so the next project does not rediscover it at 2 a.m.
You can try the migrated result here: https://qwenstremlint.tubesaku.com/
One target architecture that keeps coming up, especially for companies whose trigger for migrating is China market entry, looks like this:
CloudPort's reference migration uses exactly this pattern: the application on Function Compute calls Model Studio for inference and reaches MongoDB Atlas Vector Search through the official MongoDB MCP server. Two details from that experience are now baked into the skills. First, MCP servers launched through a package runner at cold start will not survive on the Custom Runtime — invoke the runtime binary directly with dependencies bundled at build time. Second, embedding vectors from different models are not interchangeable, so switching embedding models means re-embedding the corpus and regenerating the index; the validation skill checks dimensions before recommending anything that would trigger a billable rebuild.
If your target looks like this, it is not a special case requiring a bespoke design. It is the path the skills were written against.
There is a piece of operational knowledge here that is easy to discover too late, so it is worth stating explicitly.
If your reason for migrating is China market entry, note that publishing a public website from a mainland China region is subject to a regulatory filing and review process. It is a normal, well-documented procedure, but it is not instant, and it is not something you can leave until the week before launch. Plan for it at the start of the project, in parallel with the technical work, rather than discovering it after the application is already built and tested.
For the demo in this article, the deployment therefore runs in the Japan (Tokyo) region, with the custom domain fronted by Cloudflare. That combination is convenient — Cloudflare terminates TLS for you, so you get HTTPS on your own hostname without managing certificates.
But there is a specific ordering trap:
That orange cloud is the Proxied toggle. If you turn it on before Function Compute has finished verifying your custom domain, domain verification will not complete. Function Compute needs to see the DNS record resolving to its own endpoint; with Proxied enabled, the record resolves to Cloudflare instead, and the check never passes.
The order that works:
CNAME record pointing at your Function Compute endpoint with Proxied off (DNS only, grey cloud).If you have already hit this, the fix is the same sequence: toggle Proxied off, let verification pass, toggle it back on.
Nothing but the tokens, and about ten minutes.
# 1. Install Qwen Code and authenticate against Model Studio
bash -c "$(curl -fsSL https://qwen-code-assets.oss-cn-hangzhou.aliyuncs.com/installation/install-qwen.sh)" -s --source bailian
# 2. Install the skills
git clone https://github.com/webbigdata-jp/cloudport-agent.git
mkdir -p ~/.qwen/skills && cp -R cloudport-agent/skills/. ~/.qwen/skills/
# 3. Open any repository and ask
cd /path/to/your-repo && qwenInside Qwen Code, /skills lists what is available, and /approval-mode auto is the recommended setting for long autonomous sessions: routine reads, in-workspace edits, builds, and tests proceed, while risky commands still stop for a decision. Do not use YOLO mode on an unfamiliar production repository.
The full demo prompt for an end-to-end migration is in docs/demo-prompt.md.
The industry's mental model of migration is that the hard part is the rewrite. In practice, the projects that stall do not stall on the rewrite. They stall because a company cannot describe its own system well enough to ask for help with it — and every downstream step, including the NDA, the estimate, and the statement of work, depends on that description existing.
So the first skill CloudPort Agent offers is not a migration skill. It is a map.
Once the map exists, the rest is engineering, and engineering is the part we already know how to automate: scan, plan, patch, test, repair, package — with the human keeping the credentials, the budget, and the deploy button.
CloudPort Agent is open source under Apache-2.0 at github.com/webbigdata-jp/cloudport-agent. Issues, forks, and profiles for new source stacks are welcome.
CloudPort Agent was built as an entry to the Global AI Hackathon Series with Qwen Cloud.
Three live sites are referenced in this article and in the repository:
| Site | What it is |
|---|---|
| https://soccer.tubesaku.com/ | The original application, before migration |
| https://qwen-soccer.tubesaku.com/ | The migrated version running on Alibaba Cloud (partial dataset only) |
| https://qwenstremlint.tubesaku.com/ | The migrated multimodal sample application on Function Compute |
All three are operated on a limited-time basis, for the duration of the hackathon and the World Cup period. They are demonstrations rather than permanent services, so expect them to be taken down; the repository, the example code, and the generated architecture report remain available regardless.
The YouTube data shown on soccer.tubesaku.com and qwen-soccer.tubesaku.com comes from YouTube analytics site tubesaku.com.
Disclaimer: The views expressed herein are for reference only and do not necessarily represent the official views of Alibaba Cloud.
Alibaba Cloud Community - January 4, 2026
Alibaba Cloud Community - May 28, 2026
Alibaba Cloud Community - June 30, 2025
Justin See - March 20, 2026
Alibaba Cloud Community - June 1, 2026
Alibaba Cloud Community - July 8, 2026
Qwen
Full-range, open-source, multimodal, and multi-functional
Learn More
Function Compute
Alibaba Cloud Function Compute is a fully-managed event-driven compute service. It allows you to focus on writing and uploading code without the need to manage infrastructure such as servers.
Learn More
Alibaba Cloud Model Studio
A one-stop generative AI platform to build intelligent applications that understand your business, based on Qwen model series such as Qwen-Max and other popular models
Learn More
YiDA Low-code Development Platform
A low-code development platform to make work easier
Learn More