Reference Guide · Kit-Agnostic

Sony Infrastructure Migration Guide

The playbook for moving any RCA Kits deliverable onto Sony-owned infrastructure. Applies equally to the D2C Activations Kit, future Phases Framework Kit, and any other operations product built at RCA.

Why this exists

Each RCA Kits kit ships in a "scaffolding" stack — personal Airtable workspace, public GitHub repo, Netlify hosting, simple password gate. That's intentional: it gets a label to working software in days instead of months. But scaffolding is not the destination.

The destination is fully Sony-owned across all four layers: domain, hosting, authentication, and data. This guide describes how to get there.

Core Principle
Each of the four layers can migrate independently, on its own timeline. Nothing requires a coordinated cutover. Recommended sequence is cheapest-first.

The four layers

Layer
Name
Today (scaffolding)
Sony (destination)
Lift
01
Domain The URL where users land.
From{label}.mugzyboez.co (Manus-hosted personal subdomain)
Tooperations.{label}.sony.com or equivalent Sony-issued subdomain
Easy
02
Hosting + Code Repo Where the static files live and deploy from.
Fromgithub.com/{personal}/{repo} + Netlify auto-deploy
ToSony enterprise GitHub + Azure Static Web Apps
Medium
03
Authentication How users prove they should see the content.
FromSHA-256 password gate stored in sessionStorage
ToSony Entra ID single sign-on (no separate password)
Medium
04
Data Layer Where the kit's data is stored. Heaviest layer because all integrations point here.
FromPersonal/team Airtable workspace
ToSony-enterprise Airtable license, OR Microsoft Dataverse if Power Platform-native is preferred
Hardest

Recommended sequence

  1. Domain first. Cheapest, lowest-risk, and the most visible change. Once users see the Sony URL, the product feels Sony-owned even if everything behind it is still scaffolding.
  2. Hosting + repo second. Code moves to enterprise GitHub, deploys shift to Azure Static Web Apps. Production traffic is now flowing through Sony infrastructure end-to-end except for auth and data.
  3. Auth third. Replace the password gate with Entra ID. This eliminates the shared-password risk entirely and gives every user their own identity in the system.
  4. Data layer last. This is the heaviest because every population script, automation, and integration points at the Airtable base. Plan a real migration window.

Sony-specific tracks per layer

Domain & DNS
Sony Global Technology controls the *.sony.com namespace. Request a subdomain through standard IT ticket workflow. CNAME the new subdomain at whatever target the destination host provides (Azure Static Web Apps URL, custom Sony hosting endpoint, etc.).
Hosting + Repo
Sony has an existing Azure provisioning track that already covers RCA. Brian Lynch (Sony IT) is the canonical contact for Azure resource provisioning, including Static Web Apps and Entra ID. Sony enterprise GitHub is provisioned through the same IT channels.
Authentication
Sony Entra ID is the standard identity provider. Azure Static Web Apps integrates natively with Entra ID — once the site is deployed there, enabling auth is a configuration change, not a code change. The password gate JavaScript in the kit can be removed entirely.
Data Layer — Option A: Airtable Enterprise
Sony has Airtable licensing in some parts of the org. Lightest migration path — schema and population scripts work as-is. Just create the base inside the Sony-enterprise workspace and reroute API tokens.
Data Layer — Option B: Microsoft Dataverse
Sony runs Microsoft Power Platform, and Dataverse is its native data layer. Schema specs (markdown) port 1:1 — single-select fields become Choice columns. Heavier migration but aligns with the rest of the Sony Microsoft stack. Best fit if the kit is moving toward Power Apps interfaces (e.g. the Rate Card Calculator pattern).

What stays the same regardless of layer

The kit's schema spec. The schema lives in markdown — it is the migration document. Whether the data layer is Airtable, Dataverse, or anything else, the schema spec is what gets translated.

The dashboard front-end. Static HTML that reads from a configurable data source. The only thing that changes between Airtable and Dataverse is the fetch URL and the auth header — the rendering layer is unchanged.

The populate scripts. These are tied to the source system, so they DO get rewritten on data-layer migration. But because the schema is the source of truth, regenerating them is straightforward.

Quick reference: what to ask for, and from whom

For any RCA Kits kit moving to Sony infrastructure, these are the typical asks: