Which law firm technology projects are usually outside recurring managed IT support?
Recurring managed IT support usually covers the ongoing services defined in the agreement, not every change a law firm may want to make. Office moves, major migrations, new system deployments, infrastructure upgrades, security assessments, and incident-response engagements often need separate scope. Before work starts, confirm who is responsible, what is included, how approvals work, and what handoff the firm will receive.
Why might a technology request need separate project scope?
The difference is the nature of the work, not whether it involves technology. A routine user issue or agreed maintenance task may fit recurring support. A change that affects systems, workflows, vendors, or multiple users may need discovery, scheduling, testing, and a defined completion point.
For example, restoring one person's access may be a support request. Moving a firm's document management system involves broader questions: what data moves, how permissions are preserved, who validates the results, and how staff will work during the transition.
There is no universal list of included services. Agreements differ in what they cover, and the same request may be treated differently under different contracts. Review the service description, exclusions, project terms, and any responsibility matrix rather than relying on the label "managed IT."
Six common areas to check for separate scope are office moves, major migrations, system deployments, infrastructure changes, security assessments, and incident response.
A clear boundary lets routine support continue while planned change receives appropriate attention. Confirm that boundary before scheduling the work.
Does an office move or buildout usually need its own scope?
Often, yes. An office move or buildout can involve work beyond help desk support, such as connectivity planning, network equipment, cabling, device placement, access control, and coordination with a landlord or other vendors. Construction timing and third-party dependencies can affect when systems are ready.
For a law firm, a technical delay can disrupt access to email, matter files, phones, and remote work. Before the move, identify which services must be available on day one and who will confirm each one is working. Include the staff who depend on those systems in planning and testing.
Ask the provider to spell out whether discovery, design, vendor coordination, installation, testing, documentation, and handoff are included. Also ask what is excluded. Do not assume that cabling, construction coordination, new equipment, or ongoing support for newly installed systems are part of an existing monthly service.
GDS Technology provides technology services that include low-voltage and structured cabling, cloud services, Microsoft 365 management, and physical security. For a law firm considering a buildout, clarify the project boundary and the ongoing support arrangement before work begins. Related details are available on the structured cabling and low-voltage services page.
Define when project work ends and recurring support begins. That handoff should identify the systems delivered, the documentation provided, and who handles follow-up issues.
Are migrations and major system changes part of the monthly service?
Not necessarily. A significant change to email, cloud storage, identity, document management, practice management, billing, or network infrastructure can affect data, permissions, integrations, and daily work. It may require planning and coordination with application vendors in addition to routine IT support.
Before approving the work, name the business owner, technical owner, application vendor, and person authorized to approve changes. Agree on what will move or change, how access and data will be checked, and how staff can report problems. Ask what recovery or rollback steps are planned if the change does not work as intended.
Schedule the work around the firm's actual calendar. A major change during a filing deadline, trial preparation, or billing cycle can create avoidable disruption. Coordinate the timing with the people who use the system and give them clear instructions about what to expect.
Request an explicit list of included tasks. Discovery, configuration, migration, integration work, user testing, training, and post-change assistance may be handled by different parties or priced separately. Confirm who is responsible for each task instead of assuming one provider owns the entire chain.
A useful handoff records the final configuration, known dependencies, support contacts, and unresolved items. Confirm that the firm knows where to direct questions once the project closes.
Do security assessments and incident response sit outside routine support?
They may. Routine monitoring and help desk support are different from a time-bounded security assessment, a response to a suspected compromise, or work to answer a client security questionnaire. The agreement should say what cybersecurity work is included and what requires separate authorization or scope.
For an assessment, define the systems and accounts in scope, the questions to be addressed, who can authorize access, and what deliverable the firm needs. Clarify how findings will be shared and who decides what action to take. A technology assessment should not be represented as a legal opinion or proof that every contractual or regulatory obligation has been met.
For a suspected incident, identify the escalation route before one occurs. Decide who can authorize containment steps, who communicates with stakeholders, and when counsel, an insurer, or an application vendor should be involved. The firm should direct legal decisions and evidence-handling requirements.
Review the agreement for incident coverage, response responsibilities, and exclusions. If the work needs separate authorization, establish who can approve it and how the provider will communicate scope and next steps. GDS Technology lists cybersecurity services and IT compliance services among its offerings.
Agree on authority, scope, and communication before security work begins. A documented decision path helps the firm respond deliberately when time matters.
How can a firm tell whether a request is a project?
Start with the desired outcome. Ask whether the request restores an existing service within agreed responsibilities or changes the environment, adds a capability, coordinates multiple vendors, or needs a formal acceptance decision. The answer helps identify whether ordinary support is enough or whether the work should be planned separately.
Before approving project work, ask for written answers to these questions:
- What outcome will the work deliver, and what is explicitly excluded?
- Which systems, offices, users, and vendors are involved?
- Who approves access, business changes, and completion?
- What testing, documentation, and handoff are included?
- How will scheduling account for client and matter deadlines?
- What support applies after completion, and when does it begin?
When work touches confidential files or specialized legal applications, clarify who can access data and how vendor access is controlled. Identify who approves temporary access and who removes it when the work ends. These details make responsibilities easier to track without assuming that every party has the same role.
A commercial real estate client described the value of follow-through this way: "GDS Technology answers every question we throw at them and actually follows through to solve it. You get real answers, not deflection, and the problem gets fixed, not just talked about. They make it easy to bring them anything and walk away with a result.", Ashlee, commercial real estate client. This reflects her experience, not a promise of a specific project outcome.
GDS Technology works with organizations in Georgia, Indiana, and nationally. For a law firm evaluating a provider or planning a transition, list recurring work separately from planned changes and identify the vendors involved. Ask for an ownership map before setting a transition date.
Write down the next project, its business owner, its dependencies, and its handoff criteria. Clear scope helps routine support and planned change proceed without competing assumptions.
Frequently Asked Questions
Are law firm software upgrades included in managed IT support?
Not automatically. Routine maintenance may be covered when the service agreement says so, but a major upgrade can require planning, vendor coordination, testing, configuration changes, or staff preparation. Ask the provider to distinguish routine upkeep from project work and specify who owns licensing, application-vendor coordination, data checks, user testing, and post-change support.
Who is responsible when a legal application vendor and IT provider share work?
Responsibility should be stated in writing before a change or troubleshooting effort begins. Identify who supports the application, who manages devices and connectivity, who can approve vendor access, and who coordinates escalation. A responsibility matrix helps the firm avoid gaps without assuming either provider controls work outside its agreed scope.
What should a law firm ask before approving an IT project?
Ask for the intended outcome, inclusions, exclusions, schedule, dependencies, approval authority, testing approach, documentation, and handoff plan. For work involving client information, clarify access and data handling with the firm's decision-makers. Confirm what ongoing support applies after completion and when that responsibility starts.
How should a law firm handle project work during an IT transition?
List open projects, planned changes, vendor dependencies, and approval owners before the transition date. Ask the incoming provider what it will assume, what remains with the outgoing provider, and what needs separate authorization. Agree on a handoff for documentation, access, and unresolved work so routine support is not mistaken for project delivery.
