By name: dc-migration
description: >
Add or migrate an Agoda Cronos service's appsettings to any new data center (DC).
Use when the user says "migrate to [DC]", "add [DC] DC", "create appsettings for new DC",
"set up appsettings..json", "onboard to a new data center", or names any DC like
MY, SG, AS, AM, HK and wants a new config created.
Covers the full end-to-end workflow: duplicate config, replace DC prefixes,
verify URLs via Sourcegraph and Slack, fix discrepancies, and escalate
unverified URLs with direct Slack channel links and evidence.
DC Migration Skill
Guides the full workflow for adding a Cronos service's appsettings.<dc>.json
for any new Agoda data center.
Evidence rule
Always show evidence when verifying or escalating. Never say "confirmed" without quoting the exact source. For every ✅ or ❌ result:
- Sourcegraph: name the repo and file where the value was found
- Slack: quote the exact message text, name the author, and include the direct permalink to the message (not just the channel)
Known DC prefix mappings
| DC | Short prefix | Long prefix |
|---|---|---|
| HK | hk |
hkg |
| MY | my |
mys |
| SG | sg |
sgp |
| AS | as |
ash |
| AM | am |
ams |
If the user is migrating to a DC not listed above, ask them to confirm the short and long prefix before proceeding.
Step 1 — Identify source and target DCs
Ask the user:
- Target DC — which DC are we adding? (e.g. MY, SG, AS, AM)
- Source DC — which existing file to copy from? Default: pick the geographically closest or most similar DC (e.g. HK → MY, HK → SG).
If the target DC's short/long prefixes are not in the table above, ask the user to confirm them before proceeding.
Then duplicate the file:
cp appsettings.<source>.json appsettings.<target>.json
Step 2 — Replace DC-specific prefixes
Ask the user which keys should be updated, or use the standard set below if they
say "all DC-specific keys". Only replace values inside the listed keys — never
touch keys like ServiceName, template IDs, client IDs, tokens, or CORS lists.
Standard keys that contain DC-specific hostnames:
| Key path | What to replace |
|---|---|
NonPropertyContentApiConfig.Urls |
short prefix (e.g. hk → my) |
HermesConfig.Url |
long prefix (e.g. hkg → mys) |
ProxyConfig.Url |
use DC-agnostic http://proxy.agoda.is:3128 — see note |
PostBookingBapiAction.Urls |
short prefix |
CustomerSupportConfiguration.EnigmaConfiguration.Servers |
short prefix |
PresalesConfiguration.SubmissionConfiguration.BaseLandingUrl |
long prefix |
PromotionApiConfig.Urls |
short prefix |
CuscoConfig.CuscoApiUrl |
long prefix |
CcApiProxyConfig.Hosts |
short prefix |
FraudApi.HostName |
short prefix |
CaptchaConfig.Proxy |
use DC-agnostic http://proxy.agoda.is:3128 — see note |
ProxyConfig.Url / CaptchaConfig.Proxy note: Use http://proxy.agoda.is:3128 for
all DCs — it's DC-agnostic and resolves to the local sisproxy automatically. Do not
use DC-specific sisproxy hostnames.
Evidence — Beer (Chavanvit Krissnavarun) in
#privatecloud-my-dc-migration: "proxy.agoda.is is basically dc agnostic url for sisproxy, behind this url it will actually resolve to local sisproxy anyway" permalinkFern (Natcha Wattanaarunkij) in
#privatecloud-my-dc-migration: "BTW, recommended DC-agnostic sisproxy URL is http://proxy.agoda.is:3128" permalink
Also check: Compare the new file against other DC files (e.g. SG, AS) to catch
any keys that HK is missing. For example, CaptchaConfig.Proxy exists in SG/AS but
not in HK — if the service uses Captcha, the new DC file may need it added.
Apply replacements carefully: replace the long prefix first (e.g. hkg → mys),
then the short prefix (e.g. hk → my). This prevents the long prefix from
accidentally getting partially replaced if the short replacement runs first.
Step 3 — Verify all changed URLs
For every value changed in Step 2, run the /company-search skill to verify
each hostname. It will search Sourcegraph, Slack, and Glean in sequence and
return evidence for each finding.
DC migration specific hints to pass to /company-search:
- Scope Sourcegraph searches to
file:appsettings.<target>.json - Include
in:#privatecloud-my-dc-migrationandin:#my-dc-migrationin Slack searches - For channel lookup via Glean, ask specifically about DC-specific hostnames
Common mismatch to watch for: EnigmaConfiguration.Servers — the server
number range differs by DC (e.g. HK uses 2006–2009, MY uses 9006–9009).
Never assume the numbers just change prefix — always cross-check via Sourcegraph.
Fix any mismatches (⚠️) immediately. Collect all ❌ unverified items for Step 4.
Step 4 — Escalate unverified items
For all ❌ items returned by /company-search, present to the user as a table:
| Config key | Current value | Channel (with permalink) | Ready-to-send question |
|---|
Each question should include: ticket reference, source DC hostname, tentative target value, and a direct ask for confirmation.
Step 5 — Commit and push
After all verifications and fixes are done, use /commit-changes to stage,
commit, and push. Suggested commit message format:
[TICKET]: Add [DC name] ([dc]) data center appsettings
For follow-up fixes (e.g. correcting server numbers or wrong hostnames found during verification):
[TICKET]: Fix [ConfigKey] values for [dc] DC