Legacy Data Warehouse phase-out — Customer Impact Assessment

Legacy Data Warehouse phase-out

How to assess the impact on your organisation

Mobile Service Cloud — legacy Data Warehouse (robindwh.robinhq.com)

A practical guide for BI specialists, data engineers, developers and IT administrators

Why you received this

Your organisation still has an active connection to the legacy Mobile Service Cloud Data Warehouse — the direct SQL Server database historically reachable at robindwh.robinhq.com. This environment is being phased out and will be deactivated.

Many organisations set this connection up years ago. The people who built the reports on top of it may have moved on, and the connection may still be live while nobody actually looks at the output any more. Equally, it may be feeding a report that your service management team relies on every morning.

This document helps you find out which of the two is true, before the environment is switched off.

We will not deactivate your legacy database until you have confirmed it is safe, or until the transition is complete.

The 30-minute quick check

If you only do one thing, do this. These three checks answer "is anything still using it?" faster than anything else:

1. Ask your network or security team to search DNS and firewall logs for the hostname robindwh.robinhq.com, and for outbound traffic to it on TCP port 1433, over the last 90 days. Traffic means something is still connecting; silence is strong evidence that nothing is.

2. Search your BI platform for the hostname. In Power BI, Tableau or Looker, search data sources / semantic models for robindwh or robinhq. See §4.1–§4.2 for exactly where to look.

3. Ask us. Reply to this email and we will check whether there has been recent query activity against your legacy database, and which IP addresses are currently allowed to reach it. Every allowed IP address is a system in your organisation that was connecting at some point — that list is a shortcut to your inventory.

If all three come back empty, you can very likely let the environment be retired. Record who checked and when, then tell us. If any of them come back with a hit, continue with §3 onwards.

1. What exactly is being phased out

What is not changing: Mobile Service Cloud itself. Your inboxes, conversations, channels, automations and the standard reporting inside the product are unaffected. This phase-out concerns only the separate reporting database and anything built on it.

2. What replaces it

The legacy environment is replaced by the MSC DataWarehouse. The important differences from your side:

• Your own database. A dedicated Azure SQL database per subscription, which you query directly with the same kind of tooling you use today.

• Self-service. You manage users, permissions, firewall / IP allow-listing and credentials yourself, through the DataWarehouse app in the CM.com platform (9-dots menu → DataWarehouse).

• Sync frequency. Most data points are synchronised every 5 minutes; a small subset is real-time.

• Documented schema. The full list of tables and fields you receive is published at https://developers.cm.com/mobile-service-cloud/docs/data-documentation

• Entitlement. Raw Data Warehouse access requires an active Agent Inbox Pro subscription. If you are unsure whether this is in place, ask your Customer Success Manager.

Tables available at the time of writing — check the link above for the authoritative and current list, including which fields are real-time:

Categories · ChannelAccounts · Channels · ConversationActions · ConversationContexts · ConversationGroups · Conversations · ConversationTags · DailyOpeningHours · LogLines · Messages · NV_CallItems · NV_Presence · NV_VoiceCalls · Participations · People · Profiles · SalesPerformances · StatusReasons · TagCategories · Tags · Templates · UserPresenceLogs · Webstores · WebstoreUsers

Migrating to the new DataWarehouse is not the only option. If you do not actually need a SQL database of your own, standard MSC Analytics, the Conversations & Reporting API or scheduled CSV exports may cover what you use the legacy database for, with less to maintain. Discuss the options with your CM.com contact.

3. How to approach this

Two questions need answering, in this order:

1. What connects to the legacy database? — the inventory (§4)

2. Which of those connections are genuinely still in use? — the evidence (§5)

Everything after that is your own call: who owns each item, what it is worth, and whether you migrate it, replace it or retire it. What we need back from you is the conclusion — whether the legacy connection can be switched off, and if not, what you intend to do with it and by when.

4. Step 1 — Find everything that connects

4.0 What to search for

Use these strings everywhere you can search: repositories, file shares, configuration stores, BI platform metadata, secret managers, ticket systems and wikis. Case-insensitive.

Also note: your legacy database name and the SQL login used for it. Once you know them, search for those too — a report may reference the database name without the hostname (for example when it goes through an ODBC DSN or a gateway alias).

4.1 Power BI

Check all four of these; they hide different things.

Power BI Service (the web portal)

• Open each workspace → for every semantic model (dataset): Settings → Data source credentials and Gateway connection. The server and database are listed there.

• Use Lineage view per workspace for a visual map of which reports depend on which model and source.

• Check Refresh history on each model. A model that has refreshed successfully in the last week is live. A model whose refresh has been failing for eight months is not, and is itself a finding worth reporting internally.

On-premises data gateway

Manage connections and gateways → Connections. Every gateway connection lists server and database. This is where a forgotten scheduled refresh is most often found.

Power BI Desktop (.pbix files)

• Open the file → Transform data → Data source settings, or Advanced Editor to read the M query and see the server name in Sql.Database(...).

.pbix files are compressed, so a plain text search across a file share will not find the hostname inside them. Open them, or use the tenant-wide scan below.

Tenant-wide scan (recommended if you have more than a handful of workspaces)

With the MicrosoftPowerBIMgmt PowerShell module and Power BI admin rights:

Install-Module -Name MicrosoftPowerBIMgmt -Scope CurrentUser
Login-PowerBIServiceAccount

# All datasources across the tenant, filtered on the legacy host
Get-PowerBIWorkspace -Scope Organization -All | ForEach-Object {
  $ws = $_
  Get-PowerBIDataset -WorkspaceId $ws.Id -Scope Organization -ErrorAction SilentlyContinue |
    ForEach-Object {
      $ds = $_
      Get-PowerBIDatasource -DatasetId $ds.Id -Scope Organization -ErrorAction SilentlyContinue |
        Where-Object { $_.ConnectionDetails.Server -match 'robin' } |
        Select-Object @{n='Workspace';e={$ws.Name}},
                      @{n='Dataset';e={$ds.Name}},
                      @{n='Server';e={$_.ConnectionDetails.Server}},
                      @{n='Database';e={$_.ConnectionDetails.Database}}
    }
} | Export-Csv .\powerbi-robin-datasources.csv -NoTypeInformation

Alternatively use the Scanner API (POST /v1.0/myorg/admin/workspaces/getInfo with datasourceDetails=true, then GET /admin/workspaces/scanResult/{id}), which returns datasourceInstances with connection details for the whole tenant in one sweep.

4.2 Tableau, Looker, Qlik and similar

Tableau

• Tableau Server / Cloud: Explore → Data Sources (published data sources), and Tasks → Extract Refreshes for schedules. If you have Tableau Catalog, External Assets → Databases gives you the server list directly.

• Workbook files: .twb is plain XML, so a text search works. .twbx is a zip containing a .twb.

# Plain workbooks
grep -ril "robin" --include="*.twb" .

# Packaged workbooks — unpack and search
for f in *.twbx; do
  unzip -p "$f" "*.twb" | grep -qi "robin" && echo "$f"
done

Repository query (if you have a readonly user on the Tableau PostgreSQL repository):

SELECT DISTINCT server_name, dbname, dbclass, COUNT(*) AS connections
FROM data_connections
WHERE server_name ILIKE '%robin%' OR dbname ILIKE '%robin%'
GROUP BY 1, 2, 3;

Looker — search the LookML project repository for the connection name, then check Admin → Connections for which connection points at the legacy host.

Qlik — search .qvs load scripts and app scripts for the hostname; check reload task schedules.

4.3 Excel and Access

Excel is where the long tail lives, and it is the hardest to find because the connection is stored inside a compressed file.

• Per workbook: Data → Queries & Connections → right-click a connection → Properties → Definition. The connection string is shown there.

• .odc files (Office Data Connection) are XML and are findable with a plain text search.

• Across a file share: the snippet below opens each workbook as a zip and searches the connection definitions inside it.

# Search .xlsx/.xlsm workbooks for a legacy SQL connection
Add-Type -AssemblyName System.IO.Compression.FileSystem
$root = '\\fileserver\finance'   # adjust

Get-ChildItem -Path $root -Recurse -Include *.xlsx,*.xlsm -ErrorAction SilentlyContinue |
ForEach-Object {
    $file = $_
    try {
        $zip = [System.IO.Compression.ZipFile]::OpenRead($file.FullName)
        foreach ($entry in $zip.Entries) {
            if ($entry.FullName -match 'connections\.xml|customXml/item|queryTable') {
                $reader = New-Object System.IO.StreamReader($entry.Open())
                $text = $reader.ReadToEnd(); $reader.Close()
                if ($text -match 'robin') {
                    [pscustomobject]@{ File = $file.FullName; Part = $entry.FullName }
                }
            }
        }
        $zip.Dispose()
    } catch { }
} | Export-Csv .\excel-robin-connections.csv -NoTypeInformation

Access: check linked tables (External Data → Linked Table Manager) for ODBC connections.

4.4 ETL, pipelines and scripts

4.5 Repositories, configuration and secret stores

# In each relevant repository
grep -rinE "robindwh|robinhq|Data Source=|jdbc:sqlserver:" . \
  --exclude-dir={.git,node_modules,dist,build} | tee ../robin-hits.txt

# Also check history — a connection may live only in a deployment branch
git log --all -S "robindwh" --oneline

Also sweep:

• Secret managers — Azure Key Vault, HashiCorp Vault, 1Password, Keeper, CyberArk. Search secret names and descriptions for robin, dwh, robinhq.

• CI/CD variables — Azure DevOps variable groups, GitHub Actions secrets, GitLab CI variables.

• Infrastructure as code — Terraform, Bicep, ARM, Ansible: firewall rules and NSG entries mentioning port 1433 or the host.

• Your own documentation — Confluence, SharePoint, wikis. Search for robindwh. Old runbooks frequently name the connection that nobody remembers.

4.6 ODBC data sources on workstations and servers

An ODBC DSN hides the hostname behind a friendly name, so searches for the hostname miss it entirely. Inventory DSNs across machines:

# Local machine
Get-OdbcDsn | Where-Object { ($_.Attribute.Values -join ' ') -match 'robin' } |
  Select-Object Name, DsnType, DriverName, @{n='Server';e={$_.Attribute['Server']}}

# Across a set of machines
$machines = Get-Content .\machines.txt
Invoke-Command -ComputerName $machines -ScriptBlock {
  Get-OdbcDsn | Where-Object { ($_.Attribute.Values -join ' ') -match 'robin' } |
    Select-Object PSComputerName, Name, DriverName
}

The registry locations, if you prefer to read them directly, are HKCU:\SOFTWARE\ODBC\ODBC.INI and HKLM:\SOFTWARE\ODBC\ODBC.INI.

4.7 Network evidence — the most reliable source

Everything above finds configured connections. Network logs tell you which connections are actually being made, including ones nobody documented. Ask your network or security team for:

• DNS query logs for robindwh.robinhq.com over the last 90 days, with the source IP of each query. Each distinct source IP is a system to identify.

• Firewall or proxy egress logs for traffic to that host on TCP 1433, with source IP, byte volume and timestamps. Volume tells you whether it is a real extract or just a monitoring ping.

• NetFlow / VPC flow logs, if DNS and firewall logs are not retained long enough.

Two cautions:

• Cloud-hosted consumers (a Power BI gateway VM, an ADF integration runtime, a container) may appear as a single NAT egress address. Trace it back to the workload.

• Log retention is often 30 days. A monthly report may not appear in a 30-day window. Prefer 90 days, and if you cannot get that, weight the configuration findings from §4.1–§4.6 more heavily.

4.8 Ask us — from our side

We can help close gaps in your inventory. Reply and ask for:

• Recent query activity on your legacy database — whether anything has queried it, and roughly how recently.

• The allow-listed IP addresses for your legacy database. Every entry is a system in your organisation that connected at some point. Match each one against §4.7.

• The SQL logins that exist on your legacy database, and when they were created.

• A short technical call if the picture is still unclear.

5. Step 2 — Confirm which findings are genuinely in use

A configured connection is not the same as a used one. For each item in your inventory, establish the strongest available evidence of last actual use, and record it.

5.1 Look inside the legacy database itself

If you still have credentials, these read-only queries tell you what is in there and how fresh it is. Run them against your legacy database.

Which tables exist and how big are they

SELECT  s.name AS [schema],
        t.name AS [table],
        p.rows AS [row_count]
FROM sys.tables t
JOIN sys.schemas s   ON s.schema_id = t.schema_id
JOIN sys.partitions p ON p.object_id = t.object_id AND p.index_id IN (0, 1)
ORDER BY p.rows DESC;

Objects that you or a partner created — views, stored procedures and functions built on top of the raw tables. These are the parts that will not exist in the new environment and that you will have to recreate. This is the single most commonly underestimated piece of migration work.

SELECT type_desc, name, create_date, modify_date
FROM sys.objects
WHERE type IN ('V', 'P', 'FN', 'IF', 'TF')
ORDER BY modify_date DESC;

-- Retrieve the definitions so you can port them
SELECT o.name, m.definition
FROM sys.sql_modules m
JOIN sys.objects o ON o.object_id = m.object_id
ORDER BY o.name;

Which logins exist — roughly one per consuming system:

SELECT dp.name, dp.type_desc, dp.create_date
FROM sys.database_principals dp
WHERE dp.type IN ('S', 'U', 'G')
  AND dp.name NOT IN ('dbo', 'guest', 'INFORMATION_SCHEMA', 'sys', 'public')
ORDER BY dp.create_date;

How fresh is the data — adjust the table and column names to your schema:

SELECT MAX(CreationDateTime) AS newest_conversation FROM Conversations;
SELECT MAX(CreationDateTime) AS newest_message      FROM Messages;

Query activity, if your login has the necessary permission. These may fail with a permissions error — that is expected, and in that case use §4.8 instead.

-- Query Store (requires VIEW DATABASE STATE and Query Store enabled)
SELECT TOP 50
       MAX(rs.last_execution_time) AS last_run,
       SUM(rs.count_executions)    AS executions,
       LEFT(qt.query_sql_text, 300) AS query_text
FROM sys.query_store_query          q
JOIN sys.query_store_query_text     qt ON qt.query_text_id = q.query_text_id
JOIN sys.query_store_plan           p  ON p.query_id       = q.query_id
JOIN sys.query_store_runtime_stats  rs ON rs.plan_id        = p.plan_id
GROUP BY LEFT(qt.query_sql_text, 300)
ORDER BY last_run DESC;

-- Plan-cache fallback (requires VIEW SERVER STATE; the cache is volatile,
-- so absence here does NOT prove absence of use)
SELECT TOP 50
       qs.last_execution_time,
       qs.execution_count,
       LEFT(st.text, 300) AS query_text
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY qs.last_execution_time DESC;

6. If you use a CM.com-hosted legacy dashboard

A small number of organisations have a dashboard hosted by CM.com on top of the legacy database, rather than only a direct database connection. If your team opens a statistics or wallboard screen that is not part of the standard Mobile Service Cloud interface, treat this as a separate finding in your inventory.

Migrating the database alone is not sufficient in this case — the dashboard itself needs a replacement, which may mean rebuilding it on standard MSC Analytics or in your own BI tool. This takes longer than a connection-string change, so raise it with us early.

Include in your inventory: who opens the dashboard, how often, which figures they act on, and whether those figures exist in standard MSC Analytics.

7. Migration checklist

For every item you decided to migrate:

8. Frequently asked questions

Does anything change in Mobile Service Cloud itself? No. Inboxes, conversations, channels, automations and the standard in-product reporting are unaffected. Only the separate reporting database and anything built on it are in scope.

We have no idea who set this connection up. Where do we start? Start with the 30-minute quick check on page 1, then ask us for the allow-listed IP addresses on your legacy database (§4.8). Those two together resolve most cases.

Will our historical data be available in the new environment? The new database is populated by an initial synchronisation followed by continuous updates. Ask us to confirm the history depth for your subscription before you decommission anything, especially if you report on multi-year trends. Note also that your tenant's data retention settings apply.

Can we run both environments in parallel? Yes, and we recommend it. Keep the legacy connection alive for at least one full reporting cycle after you switch, so you can compare outputs before committing.

Is the new DataWarehouse the same schema as the legacy one? Treat it as a new schema and validate field by field against the published documentation. Do not assume that swapping the hostname will work. In particular, anything you built on top of the legacy database — views, stored procedures, custom aggregations — has to be recreated.

We only need a few numbers, not a database. Do we have to migrate? No. Standard MSC Analytics, the Conversations & Reporting API, or CSV exports may be a better fit and less to maintain.

What does the new DataWarehouse cost? Raw DataWarehouse access requires an active Agent Inbox Pro subscription. Your Customer Success Manager can confirm your situation.

Who do we contact? Your regular CM.com Customer Success or Account Management contact, by replying to the email that accompanied this document.

Reference links

• MSC DataWarehouse data documentation (tables and fields): https://developers.cm.com/mobile-service-cloud/docs/data-documentation

• Mobile Service Cloud developer documentation: https://developers.cm.com/mobile-service-cloud

• The DataWarehouse app: CM.com platform → 9-dots menu → DataWarehouse

CM.com — Mobile Service Cloud. This document describes the phase-out of the legacy Mobile Service Cloud Data Warehouse environment and is intended to help you assess and act on the impact within your own organisation.