db-intranet-mis
SQL Server database project for the IntranetMIS management-information database, holding reporting views, functions and stored procedures over Phenix booking/accounts data for MIS and Tableau.
Health score
0 to 100 across seven weighted factors; nothing is hidden. Green is 75 and above, amber 50 to 74, red below 50. How scoring works.
Facts
| Languages | sql |
| Frameworks | TC db-differential-package pipeline templates |
| Runtimes | SQL Server |
| Tests / CI | none / CI in place |
| Last commit | 2023-01-03 |
| Owner | Owner unknown (mapping to be curated) |
| Domain | Data and insight (system generated; curate in repo-owners.json to override) |
| Product area | Shared platform |
| Hosted | On-prem Deployed to our own machines
|
| Releases | 1 release pipeline(s): IntranetMIS Database |
| Integration | sqlserver, linked-servers |
| Source | Open in Azure DevOps |
Risk flags
Each flag links to its glossary definition.
Dependencies in context
Entanglement
loose No binding mechanisms apply: this system needs no untangling work.
Depends on / used by
Migration playbooks
Generated from this repo's assessment data: what is feasible, what blocks it, and the steps in order. Ratings: green means actionable now, amber means sequence other work first, red means blocked, grey means not applicable.
ZDD adoption
Not applicableNot a deployed service (libraries, database definitions, desktop apps) or a retirement candidate not worth the investment. Schema repo: changes ride with the owning services under the expand and contract pattern.
SQL Server exit
Owned at estate levelThis repo is a database definition, not a service. Its future is decided by the stage 4 database-as-product work for the systems that share it, not by a service-level migration.
Containerisation
Not applicableDatabase definition repos deploy schema, not a service.
Recommended actions
Review db-intranet-mis for retirement
Dormant (last commit 2023-01-03) yet still release-linked, and nothing depends on it. Confirm remaining use, then retire and disarm its pipeline.
Impact: Shrinks the estate before the expensive work begins
proposedAssessment notes
db-intranet-mis
Purpose
Source control for the IntranetMIS SQL Server database: roughly 387 SQL scripts defining user-defined types, functions, 126 views and 253 stored procedures. The objects aggregate Phenix booking, sales-order and accounts data into MIS reporting shapes (vw_MIS_*, vw_DATA_*) and feed Tableau dashboards (vw_TABLEAU_*). The readme states it was copied from TFS to make it deployable from Azure DevOps.
Tech stack
Pure T-SQL. Create folder with idempotent object scripts (many scripted from SSMS as UTF-16, dating back to at least 2010) plus a numbered Change folder; a stub netstandard2.0 csproj exists only to drive packaging. Build uses the shared db-differential-package pipeline template.
Deployment
Included as a prod application with 1 release; build pipeline db-intranet-mis, release pipeline IntranetMIS Database. Critically, the readme warns that automated deployment only works to testqa because live IntranetMIS lacks the changelog table — production changes are deployed manually by a DBA, and live objects have drifted from what is in git.
Dependencies
No internal repo dependencies identifiable with confidence. Change scripts configure users, roles and permissions for linked servers, and views consume Phenix accounts/stats data (via same-server databases or linked servers). Tableau is the main downstream consumer.
Data stores
sqlserver:IntranetMIS — the database this repo defines.
Integration points
Direct SQL Server access for reporting tools and intranet consumers; linked-server queries into Phenix data sources.
Code health
No tests (typical for a DB repo, but there is no validation either). CI produces differential packages, yet the release path to live is manual. Last commit 2023-01-03; comments inside views flag objects as "very old... probably needs removing" since 2010. Confirmed drift between git and live.
Modernisation risks
The git-vs-live drift plus manual DBA deploys means this repo cannot be trusted as the source of truth (drift-from-live, manual-deploys). It is a classic shared reporting database coupling many Phenix schemas. Recommended: reconcile live schema into git, add the changelog table to enable automated deploys, and prune dead objects. Medium priority — low change velocity but a real operational and knowledge-continuity risk.