{"slug": "ai-agent-skills-migrating-worldcup-rag-app-gemini-and-gcp-to-qwen-and-alibaba", "title": "AI Agent Skills migrating worldcup rag app(Gemini and GCP to Qwen and Alibaba)", "summary": "A developer migrated an AI application from Gemini and Google Cloud to Qwen and Alibaba Cloud for the Global AI Hackathon Series with Qwen Cloud. The project, CloudPort Agent, documents migration traps encountered when moving the multilingual RAG app SoccerScope. Key challenges included account authentication differences, deployment strategy mismatches, and region selection issues.", "body_md": "Submission for the [Global AI Hackathon Series with Qwen Cloud](https://qwencloud-hackathon.devpost.com/) Blog Post Prize.\n\nProject: [CloudPort Agent](https://github.com/webbigdata-jp/cloudport-agent)\n\nMost AI applications today depend on one cloud, one model provider, and one set of SDK assumptions. That is convenient until it is not.\n\nIf an American model API suddenly becomes unavailable, rate-limited, too expensive, or difficult to use from a certain region, a working backup matters. Not just a theoretical backup, but a second deployment that can actually run.\n\nThat was the motivation behind this project. For the Qwen Cloud hackathon, we took an existing Gemini + Google Cloud application and migrated it to Qwen + Alibaba Cloud. Then we turned the migration knowledge into reusable Qwen Code skills.\n\nThe result is CloudPort Agent: a small agent workflow that captures the practical migration traps we hit, so the next migration does not start from a blank page. The migrated app is SoccerScope, a multilingual RAG app for discovering popular World Cup YouTube videos from different countries. Users can search viral football videos across languages and ask the agent to turn the findings into reports, social posts, or website-style summaries.\n\nThe Qwen version is a migration demo, not a production-sized deployment. It is meant to prove that the application can run on the Qwen + Alibaba Cloud stack and to document the traps we found along the way.\n\nThe original SoccerScope stack looked like this:\n\n`gemini-embedding-001`\n\nThe target stack was:\n\n`text-embedding-v4`\n\nAt first glance, this looked like a relatively easy model swap. Because the app used Google ADK, I expected the model replacement to be mostly configuration and API mapping. In practice, the migration was easier than rewriting the whole app, but it still had several nonobvious traps. Here are the six that mattered.\n\nSince the contest was hosted on Qwen Cloud, I initially created an account there. While Qwen Cloud uses email-based authentication, Alibaba Cloud relies on password-based authentication, so I reconfigured my account on Alibaba Cloud. I followed the recommendation to create a corporate account, but please be aware that verification procedures and free credit allowances can differ between corporate and individual accounts.\n\nSince the original application was designed for Cloud Run (Docker), App Engine Service seemed like a suitable choice; however, we opted for Function Compute, which has a proven track record. Although Alibaba Cloud Function Compute supports container execution, the issue was that our specific account type did not allow for a trial period, effectively mandating a production-ready setup. Consequently, we switched to an approach that utilizes the Function Compute 3.0 custom runtime instead of containers (Docker).\n\nThat means:\n\n`python3 main.py`\n\nThis was the first important lesson: a cloud migration agent should not blindly assume that \"serverless app\" means \"container app.\" The right deployment path depends on the account, the region, the billing setup, and the trial constraints. CloudPort Agent now treats deployment strategy as a decision point instead of hard-coding Docker as the default.\n\nWe first tried a mainland China region. That immediately created a custom-domain issue. In mainland China regions, binding a custom domain can require ICP filing. For many overseas developers, that is not a realistic quick-start path. The temporary Function Compute URL also was not a good public demo URL for a browser-based web app. In our case, the default URL behavior was not what we wanted for a normal website demo.\n\nThe fix was to recreate the deployment in the Tokyo region and use a normal custom-domain setup:\n\nThe migration lesson is simple: choose your region before building everything else. For an agent, this needs to be encoded as a preflight question:\n\nIs this deployment meant to be a public web app with a custom domain?\n\nIf yes, region and domain constraints should be checked before writing deployment files.\n\nSoccerScope uses the official MongoDB MCP server. In the original Docker environment, this was easy because Node.js was already available inside the container. The app could call:\n\n```\nnpx mongodb-mcp-server\n```\n\nIn Function Compute Custom Runtime, that assumption failed.\n\nThere was no Node.js binary on the expected `PATH`\n\n. Even worse, using `npx`\n\nat cold start meant the runtime might try to resolve packages over the network during startup. That is fragile in serverless.\n\nFor a while, we removed MCP entirely and fell back to direct `pymongo`\n\ncalls. That worked, but it was not a real migration of the original architecture.\n\nThe final fix was:\n\n`node_modules`\n\nduring build time.`npx mongodb-mcp-server`\n\nwith a direct `node`\n\ninvocation.This is the kind of trap that documentation rarely teaches in one place. Each component is documented somewhere:\n\nBut the failure only appears when you combine all of them.\n\nThat combination is exactly what an agent skill should remember.\n\nGemini made structured output feel simple. In the original app, we could pass a Pydantic-style response schema and expect the API to follow it closely.\n\nWhen moving to Qwen via an OpenAI-compatible API, the behavior was different. The most important lesson was not \"Qwen cannot do structured output.\" It can. The lesson was:\n\nDo not assume Gemini-style schema behavior will map one-to-one to Qwen. In our migration path, we used JSON output mode and then validated locally with Pydantic.\n\nThat exposed several practical issues:\n\nSo the replacement pattern became:\n\nThis is boring, but it is robust. CloudPort Agent records this as an API mapping rule rather than leaving the next developer to rediscover it by reading scattered examples.\n\nFor RAG, changing the LLM is only half the migration. The embedding model matters just as much. The original app used `gemini-embedding-001`\n\n. The Qwen version uses `text-embedding-v4`\n\n. Those vectors are not interchangeable.\n\nThat means the migration must include:\n\nIn our case, we used 768-dimensional embeddings. But the important rule is: verify the dimension, do not assume it.\n\nThere was also a smaller but very practical API difference.\n\nThe original Gemini embedding flow used a larger chunk size. For Qwen `text-embedding-v4`\n\n, the official batch size limit is 10 texts per request. So the migration had to change the embedding chunk size to 10.\n\nThat is not a difficult change. The problem is that someone has to notice it. This is why CloudPort Agent includes examples such as `skills/gemini-to-qwen-api-mapping/examples.md`\n\n.\n\nThe goal is not to make humans memorize every API difference. The goal is to put those small differences into a skill file so the agent can apply them consistently.\n\nThis was the funniest bug and the most embarrassing one.\n\nThe Alibaba Cloud deployment succeeded. The web app loaded. The backend was running. Then we ran a search and saw an error like this:\n\n```\nGeneration failed: agent error: No API key was provided.\nPlease pass a valid API key.\nLearn how to create an API key at https://ai.google.dev/...\n```\n\nThe app was deployed on Alibaba Cloud, but one remaining code path was still trying to call Gemini. This is where \"migration\" becomes a dangerous word.\n\nA migration is not complete just because:\n\nYou need an end-to-end smoke test that confirms the actual runtime path. There is one important nuance here.\n\nBecause the app uses Google ADK, we cannot say that every Google-related dependency disappeared.\n\nGoogle ADK itself uses Google's newer `google-genai`\n\nSDK internally. The goal of this migration was not to delete every package with \"google\" in its name. The goal was to make sure that runtime LLM calls and embedding calls were routed to Qwen / DashScope where intended.\n\nCloudPort Agent now includes verification checks for this kind of hidden coupling. It does not declare success until the migrated app can run a real end-to-end request.\n\nThe first manual migration took about three days. After encoding the lessons into Qwen Code skills, the demo migration flow became much shorter.\n\nMeasured on this project:\n\n| Item | Manual migration | CloudPort Agent demo |\n|---|---|---|\nTime |\nAbout 3 days | About 5 minutes |\nHuman approvals |\nMany small decisions | 8 approval gates |\nFile edits in the demo scope |\nManual edits across the repo | 2 file edits |\nResult |\nRunning Qwen migration demo | Reproducible migration workflow |\n\nThe point is not that every cloud migration in the world now takes five minutes. The point is that repeated migration knowledge can be captured.\n\nA human still approves important changes. The agent does the mechanical work, applies known API mappings, and checks for common failure patterns. That is the part I find interesting.\n\nCloudPort Agent is implemented as Qwen Code custom skills.\n\nA skill is not magic. In practice, it is mostly structured text: instructions, rules, examples, and known traps written in a way the coding agent can use. That simplicity is useful.\n\nThe migration knowledge is not locked inside a private service or a complicated framework. It lives in Markdown files. In theory, the same knowledge could also be adapted for Claude Code or other coding agents, although I have not tested that yet.\n\nFor this project, the useful part was not just \"use an agent.\" The useful part was:\n\nPut the migration scar tissue into files the agent can read.\n\nCloudPort Agent is available here:\n\n[https://github.com/webbigdata-jp/cloudport-agent](https://github.com/webbigdata-jp/cloudport-agent)\n\nThe demo prompt is here:\n\n[https://github.com/webbigdata-jp/cloudport-agent/blob/main/docs/demo-prompt.md](https://github.com/webbigdata-jp/cloudport-agent/blob/main/docs/demo-prompt.md)\n\nThe YouTube demo is here:\n\nIf you want to try it with Qwen Code on macOS, here is the basic setup.\n\n```\nmkdir qwen-dir\ncd qwen-dir\nnode -v\n```\n\nIf Node.js is missing, or if your version is too old:\n\n```\nbrew install node@22\nbrew link --overwrite --force node@22\n```\n\nInstall Qwen Code:\n\n```\nbrew install qwen-code\n```\n\nThen create an Alibaba Cloud account and get an API key. Please check the latest official Alibaba Cloud / Qwen Code documentation for the current authentication steps.\n\nAt the time of writing, the Singapore region has useful free quota options, so it is a good place to start.\n\nCopy CloudPort Agent's skills into your current directory:\n\n```\ngit clone https://github.com/webbigdata-jp/cloudport-agent /tmp/cloudport-agent\nmkdir -p .qwen\ncp -R /tmp/cloudport-agent/.qwen/skills .qwen/\n```\n\nStart Qwen Code:\n\n```\nqwen\n```\n\nThen try a prompt based on:\n\n[https://github.com/webbigdata-jp/cloudport-agent/blob/main/docs/demo-prompt.md](https://github.com/webbigdata-jp/cloudport-agent/blob/main/docs/demo-prompt.md)\n\nThis project started as a simple question:\n\nCan we make a real Gemini + Google Cloud app run on Qwen + Alibaba Cloud?\n\nThe answer was yes.\n\nBut the more useful result was not the migrated demo site itself. It was the list of small, annoying, migration-specific details that had to be solved along the way.\n\nDocker assumptions. Region assumptions. MCP runtime assumptions. Structured output assumptions.\n\nEmbedding batch limits. Hidden Gemini call paths.\n\nEach one is small. Together, they are why real migrations take days. CloudPort Agent is our attempt to turn those small failures into reusable agent skills.\n\nThat feels like the right direction for cloud migration: not bigger documentation, but executable memory.", "url": "https://wpnews.pro/news/ai-agent-skills-migrating-worldcup-rag-app-gemini-and-gcp-to-qwen-and-alibaba", "canonical_source": "https://dev.to/dahara1/ai-agent-skills-migrating-worldcup-rag-appgemini-and-gcp-to-qwen-and-alibaba-5dmg", "published_at": "2026-07-07 18:13:53+00:00", "updated_at": "2026-07-07 18:28:23.564628+00:00", "lang": "en", "topics": ["artificial-intelligence", "large-language-models", "ai-agents", "developer-tools", "ai-infrastructure"], "entities": ["Qwen", "Alibaba Cloud", "Gemini", "Google Cloud", "CloudPort Agent", "SoccerScope", "Function Compute", "Qwen Cloud"], "alternates": {"html": "https://wpnews.pro/news/ai-agent-skills-migrating-worldcup-rag-app-gemini-and-gcp-to-qwen-and-alibaba", "markdown": "https://wpnews.pro/news/ai-agent-skills-migrating-worldcup-rag-app-gemini-and-gcp-to-qwen-and-alibaba.md", "text": "https://wpnews.pro/news/ai-agent-skills-migrating-worldcup-rag-app-gemini-and-gcp-to-qwen-and-alibaba.txt", "jsonld": "https://wpnews.pro/news/ai-agent-skills-migrating-worldcup-rag-app-gemini-and-gcp-to-qwen-and-alibaba.jsonld"}}