How to Choose a Managed SQL Server DBA Service: Questions to Ask Before You Sign

Choosing a managed DBA provider looks simple on paper: compare a few proposals, pick a reasonable monthly fee, sign. In practice, the difference between providers only becomes visible on the worst night of the year, when a database won’t come online, or months later, when you try to switch providers and discover that nothing was ever documented.

This guide is for IT managers and CTOs evaluating a managed SQL Server DBA service. It covers why companies outsource database administration, the questions to ask before you sign and what good answers sound like, what a proper onboarding looks like, the security and regulatory points to clarify, and the mistakes we see most often.

Why Companies Look for a Managed DBA Service

Given senior DBA salaries and licensing costs that are often tied to foreign currency, building a senior in-house database team is a heavy investment, and one DBA alone can’t cover nights, holidays and sick leave. In our experience, companies looking for a managed service usually share one of these situations:

• They don’t want the cost and risk of a senior in-house team, but still need senior-level expertise.
• Their DBA has left, and the knowledge left with them.
• They’re starting a new project and need the database side designed correctly from day one.
• They have a performance problem that the application team can’t solve alone.
• They want to start BI, analytics or AI projects and need data platform expertise alongside daily operations.
• They run several platforms at once: SQL Server next to PostgreSQL, MySQL or Oracle.
• They’ve just been through a ransomware attack or a serious outage. A large share of the companies we’ve onboarded came to us right after a cryptolocker incident or a major outage.

What they’re looking for is the same: a senior team that works proactively, not just a ticket queue that reacts after something breaks.

The Questions to Ask Before You Sign

These are the questions prospective customers ask most often. They’re the right questions; what matters is how concrete the answers are.

The Database Doesn’t Live Alone

For the business, a database is the heart of the applications that run on it: the ERP, the CRM, the reporting and BI platform. Many of the slowdowns and outages we see start in the application layer: poorly written queries from third-party software, connections that are opened and never closed, transaction handling that causes blocking and deadlocks.

A good provider doesn’t stop at adding an index. It understands how your ERP and reporting tools use the database, finds where the application creates the bottleneck, and works with your application team or vendor on process-level fixes. When you evaluate providers, ask which business applications they have hands-on experience with.

What a Proper Onboarding Looks Like

The first weeks reveal more about a provider than any proposal. A serious provider should:

1. Set up auditing first. Once access is provided, agree on an audit structure that logs every action the provider takes in your environment.
2. Follow a written onboarding checklist, so nothing depends on memory.
3. Verify backups and integrity before anything else. Before touching performance or configuration, confirm that backups exist and can be restored, and that databases pass consistency checks. See How to Build a SQL Server Backup Plan and DBCC CHECKDB in SQL Server.
4. Map privileged users and the full permission matrix, and share it with you.
5. Run a full health check and share the findings in a timestamped document.
6. Fix the urgent findings without downtime, in a prioritized order.
7. Document the architecture, the HA/DR setup, an emergency action plan with checklists for a crisis, backup policies and data retention conditions.
8. Build an inventory of every server and service in scope, and start collecting a performance baseline.
9. Recommend how to move the environment towards an industry-standard architecture.

Security, KVKK and Sector Regulations

A managed DBA provider has privileged access to your most important systems, so security can’t be an afterthought. Clarify these points before signing:

• Environment, not data. A DBA provider should manage the database environment, not handle your data. Ask whether any of your data or documents will be kept on the provider’s side.
• The provider’s own security. Ask how the provider’s working environment is protected: managed devices, multi-factor authentication, segmentation, independent security audits, enterprise password management.
• Least privilege and hardening. A minimal permission matrix, together with security hardening for both the provider’s accounts and all other accounts, reduces the risk of data leakage.
• Audit and SIEM. Activity by users other than service and application accounts should be audited, and fed to your SIEM in a usable form, with the extra details (hostname, IP and so on) needed for correlation.
• Contracts. A non-disclosure agreement protects both sides; have your legal team review the data-processing terms as well.
• Your sector’s rules. Regulated sectors add their own requirements. Banks, for example, must keep their primary and secondary systems in Turkey and employ enough in-country staff to ensure continuity, whether or not they use outside support. Energy and other critical-infrastructure companies have their own audit and security expectations. Ask whether the provider already works under these rules.

The Mistakes We See Most Often

1. Looking only at the monthly fee

The most common mistake is comparing providers on the regular fee alone. What matters is whether you’re getting a senior team, how they work with your data, and what they can proactively add to your systems. A good provider should, for example, offer licensing advice, push for standardized dev, test, QA and pre-production environments, keep you continuously informed, and make the service transparent enough that you can see what’s being done. See our SQL Server Licensing Guide.

2. Not asking for documentation and reports

All work should be documented and reported. Monthly reports should keep you informed, restore tests should be run regularly, and your actual RPO and RTO should be measured and compliance reported to you on a schedule.

3. Not asking how they’ll protect you from the next disaster

A provider should guide you before problems happen: immutable backups, a DR environment, a 3-2-1 backup structure, a minimal permission matrix, and auditing that integrates with your SIEM. A ransomware attack is a bad time to discover that every backup was reachable from the domain. See SQL Server Production Outage: A Runbook for the First 30 Minutes.

4. Signing without an exit and handover plan

Comparing Pricing Models

Providers price in different ways: per server or per instance, by hours used, or as a fixed monthly fee. Coverage is the other axis: business hours only (8×5) or around the clock (7×24), and support on request versus a fully managed service with a contractual SLA. Before comparing prices, line up what’s actually included in each proposal: monitoring, proactive maintenance, reports, restore tests, upgrades, response times and the handover plan.

Checklist: Before You Sign

1. Named senior engineers, not a generic helpdesk.
2. Written SLA with response times inside and outside business hours.
3. 24/7/365 monitoring with alerts that reach a system where they’re recorded.
4. Change management and a ticketing system you can see.
5. A documented onboarding: backups and integrity first, permission matrix, health check, inventory.
6. Regular restore tests, with RPO and RTO measured and reported.
7. Monthly reports and complete documentation that belong to you.
8. Secure, audited access from managed devices with MFA; transparent, read-only tooling; no data kept on the provider’s side; NDA in place.
9. Experience with your business applications and your sector’s regulations.
10. Proactive input: licensing, environment standardization, DR and immutable backups.
11. An exit and handover plan agreed up front.

How Aryasoft Does It

Everything above is what we’d expect from any provider. This is how we meet it:

• Senior experts only. Every engineer working on your systems is senior. SQL Server, PostgreSQL, MySQL and Oracle, plus BI and AI projects, are covered by our own team, not subcontracted.
• Documented onboarding. We follow our onboarding checklist: audit setup, backups and integrity checks first, permission matrix, health check, emergency action plan, inventory and baseline.
• HELT360, our own health check tool. HELT360 was developed in-house as an R&D project at GarajX TEKMER. It works read-only and only checks configuration; it doesn’t put load on your system. The scripts it runs can be viewed in its panel, and on request all traffic it generates can be recorded as text logs. It’s fully transparent and reportable.
• Secure access. Connections come only from company-owned, centrally managed computers in our office, with multi-factor authentication. USB storage is blocked on these devices. On request, access goes through an IP-restricted VPN. Everything is logged.
• No customer data on our side. We manage the environment, not the data. No customer data or documents are kept in our working environment, which is segmented and audited regularly by an independent security firm. All information and documents stay on the consultant machine in the customer’s environment, and NDAs protect both sides.
• Experience in regulated sectors. We work with finance companies under BDDK regulation and energy companies under EPDK regulation.
• Application awareness. We know the business applications that run on the database, including Microsoft Dynamics, Logo and Mikro ERP systems and BI platforms.
• Transparent reporting. A detailed report every month, plus documentation of all work.
• Pricing and SLA. Pricing is per instance. Maintenance and support is available as 8×5 or 7×24 coverage, with response times of 2 hours during business hours and 4 hours outside them. The SLA service, a full remote DBA service in which Aryasoft manages the whole process 7×24, responds within 30 minutes during business hours and 2 hours outside them.

Frequently Asked Questions