A court e-filing module will lose vendor support in eighteen months. What timing best aligns with asset-security practice?
Select an answer to reveal the explanation.
Short Explanation
Changing planes works better while you are still on the runway, not after the engines quit mid-air. Kick off migration before support ends so courts are not filing cases on an orphaned stack. Eighteen months sounds long until procurement and testing eat the calendar.
Full Explanation
When a court e-filing module loses vendor support in eighteen months, asset-security practice is to start the migration or replacement project before end-of-support so the service remains securely supportable. Procurement, testing, training, accessibility checks, and cutover consume calendar in municipal environments; waiting until support ends leaves courts filing on an orphaned stack. Early migration preserves patchability and continuity for a critical justice workflow residents depend on.
Waiting until the first unpatched critical exploit appears after EOS before gathering requirements fails by concept: that is reactive crisis management after exposure has already begun. Keeping the unsupported module indefinitely because invoices still arrive fails—billing continuity is not patch or security support. Outsourcing e-filing screenshots to social media to abandon migration fails as an absurd, insecure non-solution that leaks court filings and abandons a proper system of record.
Exam caveat: plan replacements with lead time before EOS; eighteen months is shorter than it sounds for public procurement. Operational check: stand up a replacement project now, lock requirements and funding, run parallel testing, and complete cutover before the support cliff—not after the first exploit lands in production.