Across many telecom organisations, some of the most important network knowledge is not stored in a database, procedure or technical manual. It exists in the experience of a small number of engineers who have worked with the network for many years.
These engineers understand which alarms require immediate attention, which apparent faults can be misleading, how different generations of equipment interact and which workarounds have previously restored service during a major incident.
That knowledge can be extremely valuable. It can also create a significant operational risk.
What happens when the engineer who understands a critical legacy platform retires, changes role, leaves the organisation or is simply unavailable when an incident occurs?
This is not only a staffing problem. It is a network continuity problem.
Legacy network knowledge is different from general technical knowledge
Legacy telecom networks are rarely static or straightforward environments. Over time, equipment may have been expanded, reconfigured, partially migrated or integrated with newer technologies.
The network that exists today may be very different from the original design.
Experienced engineers often build up an understanding of:
- Historical configuration decisions
- Dependencies between legacy and newer platforms
- Recurring alarms and known fault patterns
- Equipment-specific behaviours that are not clearly documented
- Previous incidents and the steps that resolved them
- Software limitations and compatibility issues
- Workarounds developed over many years of operation
- Which changes can be made safely and which carry additional risk
This kind of knowledge is sometimes described as tacit knowledge. It comes from direct experience rather than formal training alone.
A newly recruited engineer may be highly capable and experienced with modern IP or optical networks, but that does not automatically mean they will understand the specific history, configuration and operational behaviour of an older SDH, DWDM, access or network management platform.
The wider engineering sector is already considering how changing technologies, workforce pressures and evolving skills requirements will affect access to specialist expertise. The Engineers 2030 report highlighted by EngineeringUK calls attention to the continuing need to strengthen engineering knowledge, skills and workforce development.
For operators maintaining legacy infrastructure, the challenge can be even more specific: the required expertise may relate to equipment that is no longer widely taught, installed or supported by its original manufacturer.
How key-person dependency develops
Key-person dependency does not usually result from poor management. It often develops gradually.
A particular engineer becomes the person who resolves the most difficult incidents. Over time, colleagues naturally escalate similar problems to them. They become familiar with the network’s history, know where the useful information is stored and remember how previous problems were resolved.
Because they can resolve issues quickly, there may be little immediate pressure to create a more resilient structure around that knowledge.
The vulnerability only becomes visible when that person is unavailable.
At that point, the organisation may discover that:
- Technical documents are incomplete or out of date.
- Previous fixes were never formally recorded.
- Network diagrams do not reflect the live environment.
- Escalation routes depend on personal relationships.
- Only one person understands the impact of a proposed change.
- Critical platform knowledge is not shared across the wider team.
- The original manufacturer can no longer provide appropriate support.
This can increase restoration times, delay technical decisions and place additional pressure on Level 1 and Level 2 teams during complex incidents.
When a problem moves beyond routine monitoring, initial diagnostics or established procedures, access to genuine Level 3 expertise becomes especially important. Carritech has previously explored this distinction in What Happens When a Network Issue Goes Beyond Level 1 and Level 2 Support?
Warning signs that your organisation may be exposed
Organisations do not need to wait for an experienced engineer to announce their departure before reviewing knowledge continuity.
Several warning signs may indicate that a support model is too dependent on individuals.
1. Complex incidents always go to the same person
If the same engineer is contacted whenever a difficult fault occurs, the organisation may have technical capability but not technical resilience.
Ask what would happen if that engineer could not be reached for several days.
2. Important procedures exist only in personal notes
Engineers often develop their own spreadsheets, diagrams, command lists and troubleshooting notes. These can be extremely useful, but they should not remain accessible only to one individual.
3. Network documentation no longer reflects reality
A network diagram may show how the environment was originally built rather than how it operates today. Undocumented changes, temporary connections and partial migrations can create significant gaps between the documented and live estates.
4. Changes cannot be approved confidently without one engineer
If a software update, configuration change or equipment replacement cannot proceed until a particular person has reviewed it, the organisation may be relying on that individual’s historical knowledge rather than a repeatable change process.
5. Post-incident knowledge is not being captured
Every major incident provides valuable information about the network, its dependencies and the effectiveness of the support process.
The UK’s National Cyber Security Centre recommends documenting and acting on lessons learned from incidents. Although its guidance is focused on cyber resilience, the same principle is highly relevant to telecom network operations: incident knowledge should strengthen future response rather than disappear once service has been restored.
6. Succession planning focuses only on replacing headcount
Recruiting another engineer may increase team capacity, but replacing a role is not the same as replacing years of platform-specific experience.
A successor needs access to the network’s technical history, previous incidents, operational context and established support relationships.
What legacy network knowledge should be captured?
An effective knowledge-retention programme should capture more than equipment manuals and standard operating procedures.
It should explain how the organisation’s specific network works in practice.
Network estate and dependencies
- Active platforms and technologies
- Equipment locations
- Hardware and software versions
- Connections between legacy and current infrastructure
- Services dependent on each platform
- Known single points of failure
- Systems scheduled for migration or retirement
Configuration and change history
- Configuration baselines
- Previous upgrades and patches
- Known compatibility restrictions
- Temporary changes that became permanent
- Reasons behind unusual configuration decisions
- Approved rollback procedures
Fault and incident knowledge
- Recurring alarms
- Known hardware and software faults
- Common diagnostic sequences
- Previous root causes
- Successful and unsuccessful recovery actions
- Conditions that cause intermittent problems
- Relevant logs, reports and case histories
Operational procedures
- Methods of procedure for common and high-risk activities
- Escalation criteria
- Internal and external responsibilities
- Emergency contact routes
- Access requirements and secure access procedures
- Business continuity and disaster recovery dependencies
Hardware and spare-parts requirements
- Business-critical replacement parts
- Recommended minimum stock levels
- Known high-failure items
- Interchangeable or compatible equipment
- Repair options
- Typical sourcing lead times
It is important to capture not just what engineers do, but why they do it.
A procedure that says “restart the management application before replacing the control card” is less useful than one that also explains the symptoms, the expected result and the risk of performing the steps in a different order.
Why documentation alone is not enough
Improving documentation is essential, but a document library does not automatically create support resilience.
Documents can become outdated. They may be difficult to find during an incident, or written in a way that assumes knowledge the reader does not yet have.
Knowledge transfer should therefore combine documentation with practical activities such as:
- Joint troubleshooting sessions
- Engineer shadowing
- Recorded technical walkthroughs
- Configuration and topology reviews
- Simulated incident exercises
- Post-incident reviews
- Peer review of methods of procedure
- Rotation of escalation responsibilities
The aim is to confirm that another competent person can find, understand and apply the information under real operational pressure.
The NCSC’s incident-response planning guidance similarly emphasises the importance of defined contacts, escalation criteria, documented processes, checklists and clear responsibilities.
A telecom support continuity plan should be tested in much the same way. It should not depend on the assumption that the right person will always be available.
A practical legacy knowledge continuity plan
Organisations can begin reducing key-person risk through a structured review.
Step 1: Identify people-dependent platforms
List the technologies and systems where complex work depends on one or two individuals. Include live platforms, management systems, interfaces, software tools and operational processes.
Prioritise them according to service criticality and the difficulty of replacing the required expertise.
Step 2: Map the knowledge required to support them
For each priority platform, identify the technical, operational and historical knowledge required to diagnose faults, approve changes and restore service.
Step 3: Review the quality of existing information
Confirm whether diagrams, procedures, configuration records and escalation routes are accurate, accessible and understandable to someone other than the original author.
Step 4: Create technical redundancy
Assign secondary owners, arrange knowledge-transfer sessions and give other engineers controlled opportunities to participate in complex troubleshooting and change activity.
Step 5: Strengthen the escalation route
Determine what happens when an issue moves beyond the capability or availability of the internal team.
This should include clear escalation criteria, named responsibilities, access to the required technical information and an agreed route to specialist support.
Step 6: Test the model
Run a tabletop exercise based on a realistic scenario. Assume the organisation’s most experienced platform specialist is unavailable.
Can the remaining team identify the problem, access the correct documentation, reach the right technical resource and make a controlled decision?
If not, the exercise has identified a continuity gap before it affected live service.
How external L3 support can strengthen internal knowledge
Using external Level 3 support does not need to mean replacing the internal network team or outsourcing ownership of the environment.
It can provide an additional layer of technical resilience around that team.
A structured external support model can offer:
- An additional route for complex technical escalation
- Access to engineers with experience across legacy technologies
- Support across multi-vendor and hybrid environments
- Assistance with fault isolation and root-cause investigation
- Review and development of technical procedures
- Support during upgrades, migrations and network changes
- Greater continuity when internal expertise is limited or unavailable
Carritech provides specialist L3 Remote Technical Support for legacy and hybrid telecom networks. The service is designed to complement existing operational teams and create a clearer route for handling incidents that require deeper platform knowledge.
This approach can be particularly valuable during long migration programmes. A network may be reducing in size, but the remaining services can still be business-critical and still require specialist support.
In one Carritech L3 Remote Technical Support case study, an international carrier already had Level 1 and Level 2 support in place but required continued Level 3 expertise for a large Nokia legacy transmission environment while the network was gradually being reduced.
The objective was not to rebuild the customer’s internal organisation. It was to provide the specialist escalation capability needed to keep the existing network supported during its remaining operational life.
Do not wait until the knowledge has already left
Knowledge-retention planning is most effective while experienced engineers are still available to explain the network, review documentation and transfer their understanding to others.
Once that knowledge has disappeared, the organisation may be forced to reconstruct it during an active incident, migration or service failure.
The key questions are therefore:
- Which live platforms depend on a small number of people?
- Is the most important operational knowledge documented and tested?
- Can another engineer confidently follow the existing procedures?
- Is there a reliable escalation route when internal knowledge is not enough?
- Would the support model remain effective if a key engineer became unavailable tomorrow?
If the answer to any of these questions is unclear, now is the right time to review the organisation’s support exposure.
Review your legacy network support position
Carritech’s free Legacy Network Assessment provides a practical review of your legacy or hybrid telecom environment, current support arrangements, escalation readiness, internal expertise gaps and future requirements.
The assessment can help identify where knowledge or support dependencies may be creating operational risk and whether additional L3 expertise could strengthen your existing model.
Book your free Legacy Network Assessment with Carritech and gain a clearer view of how prepared your organisation is to support its critical network infrastructure for the years ahead.
