Whether you’re migrating to a new platform, upgrading legacy infrastructure, or implementing new security and compliance protocols, your SQL Server partner isn’t just a vendor—they’re a strategic collaborator.

So, what should you expect from a SQL Server partner during your next core banking upgrade?

The Best SQL Server Partners for Core Banking Upgrades Deliver:

1. Deep SQL Server Expertise and Core Banking Systems Familiarity

Core banking environments are complex. They handle everything from transaction processing and customer account management to regulatory reporting and data security. Your SQL Server partner must understand not only the technical architecture but also the core banking systems’ operating requirements.

Expect your partner to ask the right questions about your environment, your data dependencies, your peak usage times, and your business continuity and recovery needs. The best SQL Server consultants come equipped with industry experience and a blueprint for helping banks navigate change.

Core banking system providers are experts in their own software, but they’re not always expert SQL Server administrators. That’s where a specialized SQL Server consultant adds value. They ask the right infrastructure questions, including about Recovery Point Objectives (RPOs) and Recovery Time Objectives (RTOs). These metrics help ensure your SQL environment supports your business continuity and disaster recovery needs. A knowledgeable SQL partner can turn those objectives into strategies like point-in-time recovery, automated failover, and high-availability design.

2. Rigorous Planning and a Clear Project Timeline

A core banking database upgrade isn’t something to approach casually. Your SQL Server partner should help you scope and sequence every phase of the upgrade, including:

• Environment assessments and baseline performance benchmarks
• Compatibility testing with the new infrastructure
• Backup and restore strategies for rollback protection
• Performance settings recommendations
• Cutover planning and go-live support

Look for partners who can produce a detailed project plan and who proactively manage timelines, milestones, and communication. You shouldn’t have to tolerate surprises—and neither should your customers.

3. Zero-Downtime (or Near-Zero) Migration Strategies

Unplanned downtime in core banking systems means customer impact, reputational risk, and possible regulatory scrutiny. SQL Server partners should be able to offer strategies that minimize or eliminate unexpected downtime through:

• High availability (HA) and disaster recovery (DR) design reviews
• Pre-migration dry runs to simulate live scenarios
• Staged cutovers during low-usage periods

Expect your partner to not only explain these strategies but also test and validate them in your environment before launch day.

4. Compliance and Security Oversight

With the FFIEC sunsetting its Cybersecurity Assessment Tool and CIS® Benchmarks™ gaining ground as the new standard, your SQL Server partner must be fluent in financial data security requirements.

They should review your SQL Server configuration for gaps, recommend security hardening, and help you prepare for both internal and external audits. This includes:

• Encrypted backups and secure storage
• Role-based access controls
• Configuration baselines aligned with best practices
• Detailed documentation for compliance reviews

5. Post-Upgrade Monitoring and Support

A good partner doesn’t just help you upgrade. They help you meet your regulator with confidence.

The job isn’t finished when the core system goes live. The first few weeks post-upgrade are critical. Your SQL Server partner should offer extended support to monitor system performance, resolve unexpected issues, and ensure optimal database operation.

Banks should expect:

• Real-time monitoring for performance and error trends
• Rapid-response troubleshooting
• Ongoing patching, maintenance, and tuning
• A smooth transition to in-house teams or ongoing DBA-as-a-Service

This post-upgrade care is what separates good partners from great ones.

Choose a Partner Who Understands Banking

A core banking upgrade isn’t just technical. You need a partner who is not only steeped in SQL Server but also understands your industry, speaks your language, and can deliver with precision. At The SERO Group, we specialize in helping financial institutions modernize their SQL Server environments while prioritizing SQL Server health, security, and reliability.

If you have an upgrade to core banking system on the horizon, let’s talk. We’ll help you plan, execute, and support your transition—every step of the way.

The post Choosing the Right SQL Server Partner for Your Core Banking Upgrade appeared first on The SERO Group.

What version is my SQL Server currently running?

There are several ways to check the version of SQL Server you’re currently running – all of them documented in countless places on the the web. Checking the instance property page in Management Studio and executing SELECT @@VERSION are two of the more common.

My preference is to run the following script using SERVERPROPERTY. When used in combination with Central Management Server, you can check the current level for all the SQL Server instances in your environment with one click of the Execute button.

SELECT
	SERVERPROPERTY('servername') AS Server_Name,
	SERVERPROPERTY('edition') AS Edition,
	SERVERPROPERTY('productlevel') AS Product_Level, 
	SERVERPROPERTY('productversion') AS Product_Version,
	SERVERPROPERTY('productupdatelevel') AS Product_Update_Level,
	SERVERPROPERTY('productupdatereference') AS Product_Update_Reference,
	SERVERPROPERTY('resourceversion') AS Resource_Version, 
	@@VERSION AS Version_Information 

Running the query on my Docker container instance returns the following.

Keep in mind that SERVERPROPERTY can behave slightly differently for older versions of SQL Server. ProductUpdateLevel and ProductUpdateReference, for instance, were introduced as part of SQL Server 2012. When run against an older version, such as SQL Server 2005, these will return NULL.

Running against another older SQL Server produces the following. Still, it gives you the information you need.

So, is that up to date or not for this version of SQL Server?

What is the latest update level for my version of SQL Server?

To answer that question, let’s turn to the definitive source – Microsoft. Microsoft has gotten into a fairly predictable cadence of regularly releasing updates for SQL Server. To help us keep track of the releases they’ve provided a SQL Docs page that lists all versions of SQL Server for the past 20 years. Yes, all the way back to SQL Server 2000.

The list shows the Product Version, the Latest Service Pack (if applicable), the Latest GDR (General Distribution Release), the Latest cumulative update (CU), the CU Release Date, and a link to some General Guidance for the each version. Here’s what the site looks like today, March 31, 2020.

Not sure of the difference in a SP, GDR, and CU? Here’s a blog post I wrote 12 years ago when I blogged at SQLTeam that explains the vernacular.

Additional Information

Here are a few other links that may help.

• SQL Server Release Blog – A Micosoft Tech Community blog dedicated to SQL Server Releases.
• SQL Server Builds Blog – I particularly like this blog since it shows each version along with relevant build numbers.
• SQL Server Updates – Brent Ozar also maintains a great site for keeping track of version update information.

The post Is There an Update for My SQL Server? appeared first on The SERO Group.

What does that mean?

It means that Microsoft will no longer release any updates for any version of SQL Server 2008. That includes security patches and data integrity fixes. If a hacker finds a zero-day vulnerability and publishes it to the web for all ne’er-do-wells to use, it won’t be fixed. If a new issue is discovered that could lead to data corruption or loss, no fix will be forthcoming. Discover a performance problem? Forget about it. It’s yours alone.

It’s not that Microsoft is heartless or doesn’t care. They do. But they understandably can’t support a version indefinitely. And we’ve known for a long time that this train would leave the station.

Yet many companies are still using SQL Server 2008 and SQL Server 2008 R2 for a lot of different reasons. Too many other projects, fear of a complicated upgrade path, wanting to bundle it with a larger initiative, and simply not knowing where to start are commonly cited reasons for not upgrading. Yet.

What are your options?

Now, the day has come and SQL Server 2008 has officially been mothballed. So, what can you do?

1. The “Do Nothing” Option

If SQL Server 2008 has been working well for you and you don’t see a need to upgrade, it may be that you don’t have to do anything. You could simply continue working as you currently are for a while longer and then sunset the aging applications in due course.

But before you get too excited about this, remember what you’ll forfeit, both now and in the future. Microsoft will not release any hot patches, service patches, cumulative updates, or anything else for the database platform. That’s bad, but that’s not all.

You will also be limited on your operating system upgrades. (Keep in mind that Windows Server 2008 will not be supported after January 14, 2020.)

And if you do decide to upgrade, there will be a substantial amount of technical debt to pay down. The longer you wait, the further entrenched the dated software will become and the more difficult it will be to upgrade or remove.

Although this option may be right for some organizations or instances of SQL Server, it should not be considered for any system that is connected to the internet in any way, even through a VPN. It is risky enough without the possibility of accidentally introducing malicious code.

2. The “One-for-One Upgrade” Option

Sometimes the most straightforward approach is the best approach. If you only have a handful of SQL Servers, you may be able to spin up a new virtual server for each existing database server and migrate to the new servers. This one-for-one approach makes planning and even execution relatively easy. Relatively.

To do it right, however, will take a bit of thought. Before doing anything, you’ll want to run the Data Migration Assistant to check for any potential issues with the upgrade. The DMA will help identify discontinued or deprecated features that your older systems may be using. It’ll also help you discover any potential breaking or behavioral changes that you should be aware before you upgrade.

You’ll also want to make sure you right-size the new environment and configure the new SQL Servers appropriately. Then you can migrate the databases, logins, users, jobs, linked servers, etc. to the new servers. You’ll also want to consider the service accounts used and how they access network resources such as shares used for backups.

Check out our free 5 Common Issues That May Be Putting Your SQL Server At Risk PDF for some common configuration issues we find during our SQL Assessments.

Of course, this option doesn’t consider potential gains that may be realized through server consolidation.

3. The “Consolidation Upgrade” Option

For environments with say ten to forty SQL Servers, it’s worth considering a new SQL Server landscape. The existing SQL Server environment probably grew organically over time without a lot of planning or forethought. New applications were purchased and the easiest thing to do was to spin up a new SQL Server instance for it. Over time, the number of database servers sprawled and now you may have more licenses than you actually need.

The upgrade project is a perfect time to (re)evaluate your landscape.

For this option, you’ll want to:

• Identify the scope and breadth of the project
• Run the Data Migration Assistant to look for possible upgrade issues
• Determine vendor and licensing requirements
• Collect and analyze performance data for each server to determine potential consolidation candidates
• Determine a preliminary consolidation design
• Plan and execute the project

Depending on the scope, you may also want to include a High Availability / Disaster Recovery component to the project.

4. The “Combination” Upgrade

For many environments, especially larger or more complex ones, a combination approach will likely be required, one that incorporates elements from each of the first three options.

Some applications and their associated SQL Servers will be identified as “on their way out” and the first “Do Nothing” approach will be adopted. Use them as-is until you can get rid of them.

Other servers will likely need to be upgraded using the “one-for-one” approach. This will likely apply for larger database servers where resources are a concern. It may also be the case for specific application servers whose vendors insist on sysadmin privileges to the SQL Server. You’ll likely want to separate those application databases to restrict what the vendor has access to.

The majority of the SQL Servers will hopefully be considered candidates for potential consolidation, thus saving some licensing costs and simplifying your environment.

Which option is right for you?

As with most technical questions, the answer is: it depends. There is no clear one-size-fits-all approach for an upgrade project. Consider your timeline and budget, the business requirements and the other projects you have on your plate. Then make the best decision you can.

Not sure where to start? Or don’t have the bandwidth to tackle the upgrade project? We can help. We’ve walked this path before and can help guide you as you take the journey. Give us a call and let’s talk.

The post 4 Options Now That Your SQL Server 2008 Is Out of Support appeared first on The SERO Group.

One of our Remote DBA clients recently asked me that question. They have a set of aging SQL Server 2008 R2 instances used for production, test, and development. SQL Server 2008 and 2008 R2 Extended Support ends July 9, 2019, and the company wants to upgrade those instances before time runs out. SQL Server 2019 is currently in a preview state; the official release date hasn’t been announced.

So here’s their quandary. Rolling out an upgrade is not a trivial process. At a minimum, you must:

1. Research. What applications will be affected? Do those applications need to be certified/supported by a vendor on the newer version of SQL Server? Will your internal development teams be able to sign-off on the upgrade? Are there other dependencies that must be considered? Are there other projects that will compete for key resources. 
2. Plan. The order in which the SQL Server instances are upgraded must be planned and sequenced in a way that is efficient while minimizing risk. Backups must be verified, rollback plans must be documented, and schedules must be coordinated.
3. Test.  Before upgrading the SQL Server instances, testing should be conducted to ensure that the upgrade plans will work and that the applications will continue to function.
4. Upgrade. Once you’ve researched, planned, and tested the upgrade and process, you must actually schedule and perform the upgrade. Users must be notified. 
   

These items take time to coordinate and perform. So, it would be good to start the upgrade process as soon as possible. This means not waiting for SQL Server 2019, but going with a SQL Server 2017 upgrade. 

On the other hand, since upgrading is a time-consuming and costly experience, it makes sense to future-proof the investment by upgrading to the latest version, if possible. You can plan the upgrade while waiting for the official bits to be released to manufacturing. Once SQL Server 2019 is released, you can kick the project into high gear and proceed with the testing and rollout. At the end of the upgrade, you’ll have the newest version in place. There’s no point in doing this twice if they can avoid it. 

That is the dilemma. 

But before we make a decision, we should consider some other questions. 

• How many SQL Server instances must be upgraded? 
• How long will it take to upgrade the instances?
• How much testing must be done before upgrading? 
• How long will the new hardware and/or virtual machines take to requisition? 
• Are there compelling reasons or features in the newest version that would influence your decision? (See this Microsoft Technical White Paper for SQL Server 2019)
• Are the database servers so critical that being on the “bleeding edge” is undesirable? Would it be better to wait for a CU or two before installing? 
• What are the implications of missing the Extended Support deadline? (Assuming you’re upgrading from SQL Server 2008 or SQL Server 2008 R2. If you are upgrading from a newer version, the Extended Support deadline is not as pressing. See this support document for a description of different support levels.)

So, what to do? Upgrade to a newer version now and go through the process again sooner rather than later? Or wait an indefinite amount of time in hopes that SQL Server 2019 will be released in time for you to upgrade before July 9, 2019?

We’re seeing a lot of IT shops wrestling with this dilemma. So, if this is you, you’re not alone.  Keep in mind that not upgrading comes with some significant risks so you will probably want to take that option off the table.

Clearly, there is no one-size-fits-all answer to the question. As with many technical questions, the best answer is: It depends. It depends on your priorities, your budget, your tolerance for risk, and your other activities.

Upgrading to the goodness of a newer version will be beneficial in the long run. Just make sure you take the time to do it right. Have some questions? Leave a comment. Or if you’d rather have a more detailed discussion, feel free to reach out to us by phone (888.412.7376) or by email at info@theserogroup.com.

The post Should I Upgrade Now? Or Wait for SQL Server 2019? appeared first on The SERO Group.