Our customers use staging, so developers cannot change its database directly. Each script has to go through a ticket process that can take up to a day, which makes fixing QA findings slow.
Our releases involve large SQL scripts and manually selected changes. Management has rejected both direct access and a separate environment, but still expects faster delivery. What would you tackle first?
I would tackle the release process before asking for direct staging access again. Put database changes in version control, build the release script from the selected changes, and run the same reviewed artifact through each environment. Automate deployment where possible, with approvals and scheduled execution if those controls are needed.
That reduces the manual cherry-picking problem and makes fixes traceable. An unrecorded staging hotfix might get QA moving, but it can also leave production missing the fix.
Staging is doing two jobs here. Customers need somewhere reasonably stable, while developers and QA need a place to find and fix release problems quickly. Those needs can clash even if both are legitimate.
A separate QA environment would give the team a faster feedback loop while keeping staging controlled and production-like. Since that request was rejected, ask what constraint drove the decision and whether a smaller or temporary environment would be acceptable.
For a quicker loop, look at automated database tests against a disposable SQL Server instance, potentially in a container. Apply the stored procedures and release changes, run sanity checks, then discard it.
That won't replace staging or prove the release works with every production-like dependency, but it could catch some script errors before they enter the ticket queue.
Bring management a concrete cost and a decision, not just another request for access. Track ticket turnaround, the number of rework cycles, and how much release time is blocked. Estimate the cost carefully, since a day waiting for a ticket isn't necessarily a day of salary wasted.
Then compare options: a faster ticket service, automation, or a separate test environment. Document the chosen process and its expected delivery impact so the delivery pressure can be discussed against the actual constraints.
I wouldn't migrate to Oracle just to escape this workflow. Moving a large database with lots of stored procedures is a major project, and it doesn't fix the approval process or the conflicting uses of staging. Any database migration needs its own technical and business case.
Answers are reviewed before publication.
q.508__sidepath:
Automation won't remove the approval delay by itself, so the deployment process needs an agreed turnaround time too.