October 20, 2011 at 12:19 pm
Tracing is good, but in my experience you also need to set a cutoff for people. Especially if these databases are running 2 different applications and one is "supposed" to be legacy. As an example, the last company I was with was running their Enterprise Application on an internal web-based platform. We migrated the data and moved to a new application that was software based on the client machine to access the database on a completely different server. So, for ease of transition we left the original application running and made the permissions read only. It has been 3 years, I am no longer with the company, and I know that some people there are still accessing the old application for information. Our original plan was to shut it down and retire the DB. After too much pushback, they ended up leaving it on and there are still some stragglers using it. If they had retired it and forced the users to use the new system as planned, there would have been no choice but to use the new system exclusively. Of course, you need support from the company big-wigs to do this effectively 🙂
Jared
Jared
CE - Microsoft
October 21, 2011 at 1:32 am
My high-level decommission tasks checklist (24 applications, several databases, multiple technologies etc.)
Get sign-off from appropriate stakeholder that application can be decommissioned
Create shutdown plan and timeline
Archive data - Files needed for audit trails, history, future reporting, records retention have been identified, and retained as needed
Programs, scripts, stored procedures, packages, or other application modules archived and removed from repositories or other operational source libraries as needed
Backups used only for operational recovery have been reviewed and deleted or set to delete as needed.
All executable modules or objects have been removed from clients, servers (including MS Terminal Server, etc.) as needed
All scheduled jobs or procedures in all scheduling tools have been unscheduled
Job procedures, scripts, job sets, scheduling rule set, etc., stored in production procedure libraries have been archived and deleted
Automated email messages, distribution lists, and anti-spam bypass rule sets have been reviewed and deleted.
Test, development, QA, training, and/or other non-production environments have been purged.
Task System and other incident or issue have been archived and purged
Documentation and physical artifacts have been inventoried, boxed, relocated to storage
Departmental procedures, programs and documentation have been archived and purged
Open or Client/Server Application -- Specific Tasks
DB instances and name server entries have been backed up and/or removed
Dedicated or non-person server accounts have been removed
Notifications
All notified (Stakeholder, Users, IT)
Internal Audit has been notified for review processes and results
Enterprise Reporting project team has been notified as to data files, locations, formats, and documentation of future ReportSpace data.
Closure
Stakeholders sign-off that the application is decommissioned (with noted exceptions)
As mentioned by others, sometimes you cannot remove a database as it is the only source for important legacy information.
Just to give you an idea...
October 21, 2011 at 7:46 am
liebesiech (10/21/2011)
As mentioned by others, sometimes you cannot remove a database as it is the only source for important legacy information.Just to give you an idea...
Ideally all relevent legacy data would be imported into something like a data warehouse, where it can be centrally and seamlessly queried along with data from new applications. When the business keeps going back to copies of the legacy databases, even after the applications have retired, it's evidence that there are holes in the data warehouse that need to be filled.
Over the past several years, the company I work for has acquired many companies in the healthcare management industry, in addition to using 3rd party databases for things like MPI (Master Person Index) and CRM, so we have databases scattered around everywhere. Several of the legacy applications are still online and used, which they will be for some time going forward until contracts with larger and more complex clients expire. Even so, there are ETL extracts of patient and case status history data from the legacy systems into a data warehouse. On occasion an ad-hoc reporting request from management, auditors, or a client may involve querying the legacy application database, and that's part of my role.
A few years back, I actually developed an application, what we call the Enterprise Viewer, where the user can enter search criteria for a patient, and it will lookup the patient's master record in the MPI and then query across all active legacy database to retreive case status information, consolidating it into a standardized web form display. From the user's perspective, it's all seamless, although it did take a good deal of database engineering to pull it off. It's just one more tool that we keep running parallel with the corporate database warehouse and new application platform.
"Do not seek to follow in the footsteps of the wise. Instead, seek what they sought." - Matsuo Basho
Viewing 3 posts - 16 through 17 (of 17 total)
You must be logged in to reply to this topic. Login to reply