15 - Migration Status, Call Notes & Open Questions

The living status page for the CARR -> Barry-Wehmiller / Azure migration. Captures the latest working session, the confirmed Azure target, and the open questions in flight, so the whole team (BC + CARR + BW) is working from one current picture. Updated 2026-08-07.
Triggers: "migration status", "where are we", "db access", "next steps", "open questions", "azure sql credentials", "deny public network access", "private endpoint", "ssms", "avd", "virtual desktop", "diacto".

✅ AVD is LIVE (2026-08-06): the network blocker is cleared

Barry-Wehmiller provisioned the Azure Virtual Desktop and set up BioCreative's access on 2026-08-06 (Nancy Risch). This is the in-VNet compute that clears the Deny Public Network Access block on cbsuse-sql01 — BioCreative now has an in-perimeter Windows desktop from which the database is reachable and SSMS is directly usable.

How BioCreative connects:

• Install Microsoft's Windows App (Microsoft Store; the web version at https://windows.cloud.microsoft/#/devices works only from an InPrivate browser session and is not recommended).
• Sign in with brian.elbert@carrbiosystems.com via OKTA. (Nancy's first note referenced @barry-wehmiller.com — that was a mistake; the @carrbiosystems.com domain is correct and is what OKTA accepts.)
• Devices → "Diacto" hostpool.

Date	Event
2026-08-04	Colby submits the BW Server Request for the AVD (noted in the form as a Virtual Desktop, not a Server)
2026-08-06	Nancy Risch provisions the AVD + sets up Brian's access; access-method + domain confusion resolved same day
2026-08-06	Colby + Jacob scheduling a Friday walkthrough of the migration sequence

What this unblocks and what it doesn't. The network path (Grant C) is done. Still required before Phase 1 DDL — and all able to proceed in parallel: the DB principal + db_owner (Grant B), Azure Portal Reader, written confirmation that siplatform is the correct database dedicated to CARR (not a shared BW divisional DB), and confirmation of Azure SQL Database vs Managed Instance. See "Open questions in flight" below.

🗄️ Superseded (2026-07-31): BW was provisioning an in-VNet Azure Virtual Desktop

Barry-Wehmiller selected unblock option 2 — a BW-hosted Azure Virtual Desktop (AVD) inside the VNet, deployed Azure US East. Nancy Risch made the call on 2026-07-29 and asked Colby to submit a Server Request. This was BioCreative's preferred option: it keeps all CARR data inside BW's perimeter and supplies the in-network compute Phase 2 needs regardless.

Secondary benefit — the client-tooling mismatch disappears. Because the AVD is a Windows desktop, SSMS becomes directly usable and BW's original setup instructions apply as written. BioCreative connects from macOS using Microsoft's Windows App client, so no new hardware is required on the BioCreative side.

Date	Event
2026-07-29	Nancy selects the AVD route; asks Colby to submit a Server Request with hardware specs + software list
2026-07-30	Chad confirms Windows 11, and notes BW's request form has no Virtual-Desktop option — to be flagged in the form comments. Nancy specifies the awin11 multi-session image. Colby asks BioCreative for the tool list
2026-07-31	BioCreative delivers the full specification — see 20_avd_provisioning_and_access_response.md (also sent as a co-branded Word document)

What BioCreative supplied on 2026-07-31:

• Clarified the specification target — the CPU/RAM/disk figures describe the AVD, not BioCreative's laptop. There is no hardware request on the BioCreative side.
• Recommended specification: 8 vCPU / 32 GB RAM / 256 GB Premium SSD (D8s_v5), with 4 vCPU / 16 GB / 128 GB (D4s_v5) noted as genuinely sufficient if BW prefers to trim on cost.
• Full software list — core (SSMS, VS Code + MSSQL extension, sqlcmd/bcp, Azure CLI, PowerShell 7, Git), conversion tooling (Python 3.12, Node LTS, Storage Explorer, Postgres client), and Docker Desktop as conditional.
• One question on the OS image — whether the multi-session profile persists installed tooling and local files between sessions, and whether it permits Docker Desktop (Microsoft's guidance is that it does not). BioCreative is content to use BW's standard image either way.
• Five items flagged for the provisioning window — outbound egress to the Supabase source, where the Phase 2 container image is built, file-transfer policy, install-rights cadence, and confirmation that this desktop is a migration workbench rather than the long-term agent runtime.

Remaining Phase 0 items, all able to proceed in parallel with provisioning: the database principal grant, Azure Portal Reader, written confirmation that siplatform is dedicated to CARR, and confirmation of Azure SQL Database vs Managed Instance. See "Open questions in flight" below.

🚩 The blocker this resolves (verified live 2026-07-29): the server refuses all public connections

BW credentials were issued 2026-07-27 (Chad Evans relayed a temp password from the Service Desk; ticket 445974) and Brian's BW identity now works — Outlook signs in and Microsoft Entra issues an access token for the SQL service. Identity is done.

A live connection attempt from BioCreative then failed at the network layer with this server-side message:

Connection was denied because Deny Public Network Access is set to Yes.

This is not a credential, permission, or tooling problem. It was reproduced with deliberately invalid credentials, and against both siplatform and master — the rejection happens before authentication, so it is a property of the server, not of the login. DNS confirms the cause: the server resolves via cbsuse-sql01.privatelink.database.windows.net, i.e. it is configured for Private Endpoint access only. TCP 1433 to the shared Azure gateway (20.62.132.163, East US) does complete, then the gateway resets once it routes to the server.

Consequences:

• An IP firewall rule will not fix this. Public access is denied wholesale rather than filtered, so an allowlist entry is never consulted.
• No client tool fixes this. SSMS, VS Code + MSSQL extension, sqlcmd, DBeaver — all get the identical rejection from outside BW's VNet.
• Colby's own setup works because he connects from inside the BW corporate network.
• The DB principal grant and Azure Portal RBAC remain untested — they are almost certainly also missing, but cannot be verified until a network path exists. Ask for all of them at once.

Four unblock options put to BW (2026-07-29), any one sufficient: (1) VPN access into the BW network; (2) a BW-hosted Windows VM / AVD / Azure Bastion jump host inside the VNet — BC-preferred, keeps data in-perimeter and provides the in-network compute Phase 2 needs anyway; (3) set Deny Public Network Access = No plus a firewall rule for BioCreative's IP 73.160.170.168 — simplest, least secure, likely against BW policy; (4) run the migration from Azure-hosted compute inside the VNet (container instance / Azure Data Factory). Note: BioCreative has no Windows machine and no Parallels VM, so option 2 must be BW-hosted.

✅ Resolved 2026-07-29 — BW selected option 2. See the resolution section at the top of this document.

See 19_client_tooling_and_access.md for the full explainer (what SSMS is, the macOS-supported clients, and the three independent grants required).

Latest working session - 2026-07-21

Working call on the path forward for migrating the CARR Intel Hub to Barry-Wehmiller's Azure environment. Not recorded - these are the captured notes.

• Attendees: Brian Elbert (BioCreative), Saeed Allahbaksh (Barry-Wehmiller), Colby Bishop (CARR, Product Manager).
• Frame: good alignment on the path forward; the remaining items are access + a handful of architecture decisions (below), not disagreements on direction.
• Post-call: the BioCreative Agent-Building Stack guide was shared with Colby, Saeed, and Blake Feinstein (BW Forsyth) so the BW/CARR side can see how the agents are built. It is on this site - see 16_agent_building_stack.md and the per-agent mapping in 11_carr_agent_fleet.md.

Confirmed Azure SQL target (the destination)

Barry-Wehmiller has stood up the Azure SQL database that the CARR platform migrates into. This is the real target for the Postgres -> Azure SQL conversion in 07_azure_sql_conversion.md.

Item	Value
Server	cbsuse-sql01.database.windows.net
Database	siplatform
Client tool	SSMS per BW's instructions. Resolved by the AVD (2026-07-31): SSMS is Windows-only and BioCreative works on macOS, which is why the cross-platform clients (VS Code + MSSQL extension, sqlcmd) were proposed — but because the AVD is a Windows desktop, SSMS is now directly usable and BW's instructions apply as written. See 19_client_tooling_and_access.md + 20_avd_provisioning_and_access_response.md
Auth	MFA + Barry-Wehmiller credentials (Microsoft Entra)
Brian's login	Brian.Elbert@carrbiosystems.com
Provisioned by	Landon (BW), with setup instructions handed to BioCreative

Access status (2026-08-07): credentials issued ✅, network path ✅ live (AVD provisioned 2026-08-06), DB principal ⏳ not yet granted. The BW login authenticates and Entra issues a SQL access token. The server has Deny Public Network Access = Yes and is Private-Endpoint-only; the in-VNet Azure Virtual Desktop ("Diacto" hostpool) now provides the path — see the AVD-live section at the top of this doc. Region: East US. The Supabase -> Azure SQL migration is prepped and begins the moment the database principal is granted and siplatform is confirmed dedicated.

Resolved: Identity (no longer an open question)

CARR is a BW subsidiary — all app users (@carrbiosystems.com, @bw*, @forsyth*) are in BW's Entra workforce directory. The one non-BW user (Brian Elbert, BioCreative consultant) is being provisioned a BW login (Brian.Elbert@carrbiosystems.com). No External ID / CIAM / B2B-guest complexity is needed. Straight Entra workforce auth → MSAL on frontend → Entra JWT decoded by API middleware → SET LOCAL app.user_id. Identity is not a risk item or blocker.

Open questions in flight

From the current working thread. BC's position on each is noted; final calls sit with BW/CARR.

1. Network path to siplatform (gating). ✅ Credentials issued 2026-07-27. ✅ Unblock route chosen 2026-07-29 (BW-hosted AVD, US East). ✅ Server Request submitted 2026-08-04. ✅ AVD provisioned 2026-08-06 (Nancy Risch) — "Diacto" hostpool, Windows App, brian.elbert@carrbiosystems.com via OKTA. No longer a blocker. Remaining Phase 0 items are the DB principal + confirmations below, all parallelizable.

1a-i. AVD provisioning specifics. Three sub-items BioCreative raised on 2026-07-31, none blocking the request itself: (a) outbound egress — the migration reads from Supabase (AWS us-east-1) and pushes to BW GitHub; either allow egress on 5432 or BioCreative exports locally and hands BW a file; (b) where the Phase 2 container image is built — Docker Desktop on the AVD (needs single-session), ACR Tasks, or a CI build agent; BioCreative has no preference but the choice should match the OS image; (c) image + install rights — whether the profile persists tooling/files between sessions, and whether installs route through BW packaging or local admin. Owner: BW cloud ops + Brian.
1b. DB principal + role. An Entra admin on the server must run CREATE USER [brian.elbert@carrbiosystems.com] FROM EXTERNAL PROVIDER; and grant db_owner (or db_ddladmin + db_datareader + db_datawriter). The conversion creates ~86 tables / ~101 views / ~131 procedures, so read-only is insufficient. Still not granted. Not verifiable until the AVD is live, but can be granted in parallel — no need to wait.
1c. Azure Portal RBAC (Reader) on the resource group + SQL server, so BioCreative can self-serve networking/tier/config questions instead of round-tripping each one by email. Never previously requested — newly identified gap. Re-raised 2026-07-31.
1d. Confirm siplatform is dedicated, not shared. The name and the cbsuse-sql01 server suggest a possible pre-existing BW divisional database. Landing 86 CARR tables into a live shared app DB would be wrong. Needs written confirmation from BW. Re-raised 2026-07-31; blocks any DDL.

1e. Confirm Azure SQL Database vs Managed Instance. The endpoint format indicates SQL Database, which has no SQL Server Agent — so the 21 scheduled jobs must land on Elastic Jobs or Functions timers instead. This is a real change to Phase 1 scope, so BioCreative would rather confirm than infer. Owner: BW DBA (Venkata). Re-raised 2026-07-31.
2. Data-warehouse layer - now or later? Do we add a warehouse layer now, or treat it as future-state once the platform is pulling from multiple source systems (CRM, HubSpot, XA)? BC position: future-state. Land the single-source Azure SQL migration first; add a warehouse only when multi-source consolidation is real. See 07.
3. Frontend + compute topology. Dashboard on Azure Static Web Apps talking to a backend on Azure Container Apps; BioCreative can author the Dockerfile and push the image to the Container Registry. Open: does the Container Apps + Registry deployment need a separate resource group / permissions from the one created for the DB? BC position: confirm the RG/permission model with BW cloud ops before we build the image. See 03_compute_frontend.md.
4. Agents / LLM runtime. Microsoft Foundry looks like the right home for the agents that scrape + curate data, but no Barry-Wehmiller user with Foundry access has been found yet. (Refresh 2026-08-07: Azure AI Foundry Agent Service is now GA — core Mar 2026, hosted agents ~Jul 2026 — so this is an access question, not a product-maturity one.) Open: is there anyone at BW who has used Foundry, and can CARR explore it with BioCreative - or do we fall back to recreating the agents via Claude Cowork? BC position: Foundry is the target (see 02_ai_foundry_agents.md + the fleet in 11); Cowork is a viable interim only if Foundry access stalls. The agent-build method is documented in 16_agent_building_stack.md.

Immediate next steps

#	Step	Owner	Blocked by
1	✅ Done 2026-07-27 — BW email credentials issued for brian.elbert@carrbiosystems.com	Chad Evans (BW) + Colby	-
1a	✅ Route chosen 2026-07-29 — BW-hosted AVD inside the VNet (US East)	Nancy Risch (BW)	-
1a-i	✅ Done 2026-07-31 — BioCreative supplied AVD hardware specs + software list + provisioning flags (20_avd_provisioning_and_access_response.md)	BioCreative	-
1a-ii	✅ Done 2026-08-04 — Colby submitted the Server Request (flagged as Virtual Desktop, not Server)	Colby	-
1a-iii	✅ Done 2026-08-06 — AVD provisioned + access set up ("Diacto" hostpool, Windows App, OKTA)	Nancy Risch (BW)	-
1b	Grant DB principal + db_owner on siplatform; grant Azure Portal Reader on the RG — parallelizable, now the critical path	BW Entra/SQL admin	-
1b-i	Confirm siplatform is dedicated to CARR (written) + confirm SQL Database vs Managed Instance	BW + Colby / Venkata	-
1b-ii	On the desktop: verify the connection target resolves to cbsuse-sql01/siplatform and confirm it is the correct dedicated CARR database before any DDL	BioCreative	Step 1a-iii
2	Connect + begin Supabase -> Azure SQL conversion (07)	BioCreative	Steps 1b + 1b-i
3	Confirm resource group / permissions for Container Apps + Registry	BW cloud ops + Colby	-
4	Author the Dockerfile + push backend image to the Container Registry	BioCreative	Step 3
5	Locate a BW Foundry user / confirm access path for the agent fleet	BW + Colby	-
6	Decide data-warehouse timing (now vs future-state)	BW + CARR	-

Cross-references

• Postgres -> Azure SQL conversion (targets siplatform): 07_azure_sql_conversion.md
• Compute + frontend hosting (Static Web Apps + Container Apps): 03_compute_frontend.md
• Foundry + the agent runtime: 02_ai_foundry_agents.md
• The planned CARR agent fleet: 11_carr_agent_fleet.md
• How we build agents (the shared method): 16_agent_building_stack.md
• Client tooling + the three access grants (SSMS, macOS clients, Private Endpoint): 19_client_tooling_and_access.md
• AVD specification, tooling list + remaining access items (2026-07-31): 20_avd_provisioning_and_access_response.md
• Whole-system map: ../CARR_FULL_SYSTEM_MIGRATION_MAP.md

19 - Client Tooling & Database Access: What SSMS Is, and the Three Grants Required

The "how do we actually connect to the database" doc. Explains what SQL Server Management Studio is (and is not), which clients work on macOS, and the three independent permissions that must all be in place before BioCreative can reach siplatform. Written after a live connection test on 2026-07-29 revealed that only one of the three exists.
Triggers: "ssms", "how do I connect", "sql client", "mac", "azure data studio", "db access", "deny public network access", "private endpoint", "firewall rule", "what site do I log into".

✅ UPDATE (2026-08-07): the network path (Grant C) is RESOLVED. Barry-Wehmiller provisioned an in-VNet Azure Virtual Desktop ("Diacto" hostpool) on 2026-08-06, so BioCreative now reaches siplatform from inside BW's network — and because that desktop is Windows, SSMS is directly usable, so the macOS-client workaround below is no longer needed. The three-grants explanation is preserved below for reference; the remaining open grants are the DB principal (Grant B) and Azure Portal Reader. See 15_migration_status.md for the current status.

Verdict up front

BW's setup instructions ("install SSMS, use MFA, here's the server and database") are correct in substance but incomplete, and not executable on macOS. Two separate issues:

1. SSMS is Windows-only. BioCreative works on macOS. This is solved trivially by using Microsoft's supported cross-platform clients instead — it is not a real obstacle.
2. The server refuses all connections from outside BW's network. This is the real blocker, and no client tool, credential, or firewall rule on BioCreative's side can resolve it.

1. What SSMS actually is

SQL Server Management Studio is a free Microsoft desktop application — a database IDE.

• The right analogy: SSMS is to Azure SQL what Supabase Studio, pgAdmin, or DBeaver is to CARR's current Postgres database. Object explorer tree, query editor, results grid, execution plans, security dialogs.
• It is not an SSH terminal. It's a graphical client, though it does include a query pane where you type T-SQL.
• It is a client, not the environment. It runs on your laptop and connects outbound over TCP 1433 to cbsuse-sql01.database.windows.net. Installing it grants no access by itself.
• There is no "site to log into." Azure SQL has no Supabase-style hosted web console. The only browser-based surface is the Azure Portal → SQL database → Query editor, and reaching that requires Azure Portal RBAC on the server (see §3, grant C). This is why the repeated question "which site do I log into?" had no good answer — for a database, there isn't one.

2. macOS-supported clients (all free)

Tool	Status	Notes
VS Code + MSSQL extension	✅ Recommended	Microsoft's official path. Windows/macOS (Intel + Apple Silicon)/Linux. Supports Microsoft Entra ID with MFA. Object explorer, query editor, schema designer, DACPAC, query profiler.
sqlcmd (go-sqlcmd)	✅ In use	brew install sqlcmd. Pure-Go, no ODBC dependency. Supports ActiveDirectoryInteractive and ActiveDirectoryDeviceCode auth. Best for scripted work and fast connectivity probes.
bcp (mssql-tools18)	✅ Needed later	The bulk loader for the ~104,000-contact data transfer in 07_azure_sql_conversion.md §7.
DBeaver / DataGrip	⚪ Optional	DBeaver free, DataGrip paid. Not required.
SSMS	❌ Windows-only	Per Microsoft's published system requirements, macOS is not a supported OS. Usable only from a Windows machine or a Windows VM.
Azure Data Studio	❌ Retired	End-of-life 2026-02-28; no further updates or security fixes. Microsoft directs users to VS Code + the MSSQL extension. Do not adopt.

Note: BioCreative has no Windows machine and no Parallels VM. If BW's answer is "use SSMS from inside our network," the Windows host must be BW-provided.

3. The three grants — all required, only one exists

Reaching a database in Azure requires three independent permissions. They are frequently confused with one another, which is the root of the confusion on this thread.

	Grant	What it proves	Who grants it	Status (2026-07-29)
A	Entra identity + MFA — the account can authenticate to BW's directory	You can sign into Outlook, and Entra will issue an access token for the SQL service	BW Service Desk (ticket 445974); temp password relayed by Chad Evans	✅ Confirmed working
B	Database principal + role inside siplatform	The authenticated identity is a known user of that database with permission to do things	An Entra admin on the SQL server (specific owner TBC — see routing note below)	❓ Not granted / untestable
C	Network path to the server	Your traffic is even allowed to arrive	BW cloud ops	❌ Closed — this is the blocker

Critically: signing into Outlook only proves grant A. It says nothing about B or C. That is why "I can get into the Outlook account" did not translate into database access.

Who to route to: BW contacts on record are Chad Evans (Senior Manager, Data Architecture & Data Management — relayed the credentials), Landon Godar (BW IT — provisioned the database and BioCreative's access per the 2026-07-21 notes), and Venkata (BW DBA lead — owner of the engine-standard decision). None is confirmed as the owner of the server's network configuration, so the ask should be routed rather than addressed to a guessed individual.

The T-SQL for grant B (for whoever holds the Entra admin role)

-- Run against the siplatform database, connected as the Entra admin for the server
CREATE USER [brian.elbert@carrbiosystems.com] FROM EXTERNAL PROVIDER;

-- DDL rights are required: the migration creates ~86 tables, ~101 views, ~131 procedures
ALTER ROLE db_owner ADD MEMBER [brian.elbert@carrbiosystems.com];

-- Or, if db_owner is too broad for BW policy, the minimum viable set:
-- ALTER ROLE db_ddladmin   ADD MEMBER [brian.elbert@carrbiosystems.com];
-- ALTER ROLE db_datareader ADD MEMBER [brian.elbert@carrbiosystems.com];
-- ALTER ROLE db_datawriter ADD MEMBER [brian.elbert@carrbiosystems.com];

Read-only access is not sufficient — this is a schema-creating migration, not a reporting connection.

4. Grant C — the actual blocker, in detail

What we observed (live test, 2026-07-29)

Probe	Result
DNS for cbsuse-sql01.database.windows.net	CNAME chain through cbsuse-sql01.privatelink.database.windows.net → dataslice8.eastus → gateway 20.62.132.163. The privatelink segment confirms a Private Endpoint is configured.
TCP connect to port 1433	Succeeds — but this only reaches Azure's shared regional gateway, which accepts TCP for every server in the region.
Entra device-code authentication	Token issued successfully (grant A confirmed).
TDS session establishment	connection reset by peer
Same connection with deliberately invalid credentials	Connection was denied because Deny Public Network Access is set to Yes.
Same probe against the master database	Identical message.

Why the invalid-credentials probe matters

Because the identical error appears with fake credentials and against a different database, the rejection provably happens before authentication is evaluated. It is therefore a property of the server, not of the login, the password, the database, or the client tool.

What "Deny Public Network Access = Yes" means

The server accepts connections only from inside BW's Azure virtual network, via its Private Endpoint. Consequences:

• An IP firewall rule will not help. When public access is denied wholesale, the firewall allowlist is never consulted. Adding BioCreative's IP changes nothing while this setting remains Yes.
• No client tool helps. SSMS, VS Code, sqlcmd, DBeaver — identical rejection.
• Colby's setup works because Colby is inside the network. His traffic arrives privately and resolves the privatelink name to an internal address. Brian's arrives from the public internet and is refused at the door. This is why the instructions were accurate for the author and non-functional for the recipient.

The four ways to unblock it (BW's choice)

#	Option	Trade-off
1	VPN access into the BW network for BioCreative	Fastest, if consultant VPN is an existing pattern at BW
2	BW-hosted Windows VM / Azure Virtual Desktop / Azure Bastion jump host inside the VNet	BC-preferred. Most policy-friendly, keeps all data inside BW's perimeter, and provides the in-network compute Phase 2 needs anyway. Must be BW-hosted — BC has no Windows machine. Also makes SSMS usable, since the VM is Windows.
3	Set Deny Public Network Access = No + firewall rule for 73.160.170.168	Simplest technically; least secure; likely conflicts with BW standards. Not recommended by BC.
4	Run the migration from in-VNet Azure compute (container instance / Azure Data Factory) that BC configures and triggers	Cleanest architecturally, closest to end-state; most setup effort

5. Also needed: Azure Portal Reader (grant C-adjacent)

Separate from database access, BioCreative has never been granted Azure Portal RBAC. Without at least Reader on the resource group and SQL server, every configuration question — which tier, what are the firewall rules, is public access on, where is the Key Vault, does the Container Registry exist — requires an email round-trip to BW. Granting Reader is low-risk (read-only, no data-plane access) and removes a recurring source of delay across Phases 0–4.

6. What this does and does not change about the migration

Does not change: the conversion scope in 07_azure_sql_conversion.md is unaffected — still 86 tables, 101 views, 131 functions, 252 RLS policies, 46 triggers, 21 scheduled jobs. The client tool was never going to do that work; the heavy lifting is LLM-assisted T-SQL conversion plus bcp/ADF for the data.

Does change: where the migration executes. Private-Endpoint-only means the conversion and bulk load must run from inside BW's network — over VPN, from an in-VNet jump host, or from in-VNet Azure compute. That decision should be made now, because it determines where tooling gets installed and where the Supabase export lands in transit.

One scope implication surfaced: the endpoint format (*.database.windows.net with no Managed Instance DNS zone segment, gateway cr14.eastus1-a.control) indicates Azure SQL Database, not Managed Instance. That means no SQL Server Agent, so the 21 pg_cron jobs must land on Elastic Jobs or Azure Functions timers. Pending written confirmation from BW — see decision D1 in 18_migration_roadmap.md.

Open items for BW

0. Identify who owns the network configuration for cbsuse-sql01 (Private Endpoint / public-access settings). This is currently unknown to BioCreative and is the routing prerequisite for item 1.
1. Choose one of the four network-access options in §4.
2. Run the grant-B T-SQL in §3 and confirm.
3. Grant Azure Portal Reader on the resource group + SQL server (§5).
4. Confirm in writing that siplatform is a dedicated database for the CARR platform, not a shared BW application database. The generic name plus the divisional cbsuse-sql01 server naming leave this ambiguous, and landing 86 CARR tables into a live shared system would be wrong.
5. Confirm Azure SQL Database vs Managed Instance in writing (§6).

Cross-references

• Live status + the blocker log: 15_migration_status.md
• Roadmap, Phase 0 gates, blockers table: 18_migration_roadmap.md
• Conversion scope + data-transfer runbook: 07_azure_sql_conversion.md
• Identity + DevOps + Entra: 04_github_devops_governance.md
• Plain-English Azure glossary: 06_glossary.md

Research anchors

• SSMS system requirements (Windows only): learn.microsoft.com/en-us/ssms/system-requirements
• Azure Data Studio retirement (2026-02-28) + VS Code migration path: learn.microsoft.com/en-us/sql/tools/whats-happening-azure-data-studio
• MSSQL extension for VS Code (platforms + Entra/MFA support): learn.microsoft.com/en-us/sql/tools/visual-studio-code-extensions/mssql/mssql-extension-visual-studio-code
• Entra authentication for Azure SQL + CREATE USER ... FROM EXTERNAL PROVIDER: learn.microsoft.com/en-us/azure/azure-sql/database/authentication-aad-configure
• Azure SQL IP firewall rules: learn.microsoft.com/en-us/azure/azure-sql/database/firewall-configure
• Deny-public-network-access error reference: go.microsoft.com/fwlink/?linkid=2323206 (returned verbatim by the server)
• Live connection test: BioCreative, macOS, sqlcmd 1.10.0, 2026-07-29.