Legacy App Review Cycles
Do you go back and review the schemas, design and maintenance for legacy applications, or are you more of an "if it ain’t broke, don’t fix it" type of DBA?
So many of us support legacy applications – systems that were perhaps even built on prior releases of SQL Server, using the tools and features that were part of that release. Now, with the systems upgraded and running on the latest and greatest, or even on those original versions of SQL Server, do you revisit those systems and apply both new features that may be around or new things and approaches you’ve learned?
What’s the process for review of applications? We’ve seen a significant increase in performance and have caught some mistakes and updated some "I can do better now…" type issues we’ve found in reviewing systems. It’s kicked off, with me personally at least, an informal review of some of our internal systems and even those of customers to make sure all the best practices are applied, that we’re using the best tools for the job and so-on.
Do you review systems that are already up and running and that seem "fine?" If so, what is your threshold for determining whether you should take any action? At some level, it’s worth it to update things and dig further into the systems. At other levels, it’s just not worth it.
Of course a huge number of people are out there arguing with me in their heads right about now – "I don’t have time to do my primary job – you’re saying I should invent work now?"
What do you think about all of this?
Featured White Paper(s)
SQL Server Data Protection with Auto Snapshot Manager
This Technical Report describes using Dell EqualLogic Auto-Snapshot Manager V3.0, PS Series groups, and Microsoft SQL Server… (read more)
EMC Solutions for Microsoft SQL Server 2005: EMC CLARiiON CX3 Series Physical iSCSI
With increasing demands and limited resources, today’s midsize enterprises face challenges similar to their larger counterpar… (read more)