Avaya 37820X: Legacy Midsize Solution Design and Its Successor Path

37820X was the Avaya Midsize Solution Design exam for the ACDS-3781 Avaya Certified Design Specialist credential. It assessed the ability to design midsize communications solutions around the Avaya portfolio of that period, including the requirements, architecture, resiliency, endpoints, applications, and commercial considerations needed to turn a customer request into a coherent solution.

The exam is retired. Avaya announced that ACDS-3781 and 37820X would retire on August 30, 2024. Its published transition introduced the ADRA-0008 Avaya IP Office Platform Design credential, earned through the 37611T Avaya IP Office Design Proficient Test. Because the legacy Avaya Learning Center was decommissioned in June 2026, candidates should use the current Avaya training channels and the Avaya certifications context to verify that successor path before registering.

Solution design starts with requirements rather than product selection

A midsize communications design should begin by translating customer requirements into measurable technical needs: user counts, sites, call flows, mobility, contact center requirements, survivability, integrations, security, management, and growth. Choosing products before understanding those needs risks creating a design that is impressive but misaligned with the business problem.

Legacy 37820X scenarios often reflected this design discipline. Candidates needed to determine which architecture fit the stated constraints and which added capability genuinely created value. That type of reasoning remains transferable to modern solution design because requirements and tradeoffs still come before bill-of-material selection.

Capacity and licensing are part of architecture

A design can be technically elegant and still fail if it does not support the required users, trunks, endpoints, features, or application capacity. Midsize solution architects must understand platform limits and license relationships well enough to size the environment and explain what changes as the customer grows.

The important study habit is to connect a feature to its dependency. Does it require a license, server role, gateway, endpoint type, or service? Is the capacity per system, per node, or per user? Retired exam numbers should not be used for current commercial design, but the discipline of validating assumptions against current product documentation remains essential.

Resiliency should match business impact

Customers may ask for “high availability” without defining which failures must be survived or how quickly service must recover. A designer needs to identify single points of failure, site dependencies, network assumptions, local survivability, backup paths, and operational recovery procedures. The right architecture depends on the cost and consequence of downtime.

A resilient design is more than duplicated equipment. If both systems depend on the same network, power source, carrier, or configuration error, the apparent redundancy may not protect against the relevant failure. Design questions should therefore be read as risk problems: what event is being mitigated, what remains vulnerable, and how will failover be validated?

Endpoints and user experience shape the practical design

Midsize customers can have desk phones, soft clients, mobile users, attendants, conference rooms, remote workers, and specialized contact center roles. Endpoint selection affects licensing, network requirements, security, feature availability, deployment effort, and support. A solution should match user personas instead of giving every person the same device and feature bundle.

Mobility also changes the network and security picture. Remote access, session traversal, bandwidth, identity, emergency calling, and device management can become part of the architecture. The design is strongest when user experience is treated as an engineering input rather than an afterthought once the core call server has been chosen.

Contact center features can change the architecture substantially

When a midsize solution includes contact center requirements, the design must account for agent concurrency, routing, reporting, recording, channels, supervisors, and integrations. Historical Avaya contact center exams such as 6210 belonged to a different credential generation, but they illustrate why a contact center is not simply an extension added to basic telephony.

A designer should clarify whether the customer needs basic hunt-group behavior, formal skill routing, multimedia interactions, workforce capabilities, recording, analytics, or specialized integrations. Each requirement can alter capacity, licensing, network design, and operational complexity.

Network design and voice quality remain foundational

Unified communications relies on IP networks that deliver adequate bandwidth, latency, jitter, packet-loss performance, segmentation, addressing, and quality of service. A design that ignores the existing LAN and WAN can produce poor voice quality even when the communications platform itself is correctly configured.

Candidates studying legacy design material should focus on transferable network principles rather than old switch models. Site topology, uplink capacity, Power over Ethernet, VLANs, QoS trust boundaries, DHCP options, DNS, time services, and WAN behavior are all examples of dependencies that connect communications design to the underlying network.

Commercial choices influence technical choices

Midsize solution design often balances capital cost, subscription or support models, deployment effort, feature tiers, growth, and operational support. A feature that appears free at initial purchase can still create training or support cost; a lower-cost architecture can become expensive if it needs redesign for growth. Designers should make tradeoffs explicit rather than treating price as a separate sales conversation.

Good architecture communicates assumptions. If capacity is sized for a particular growth rate or resiliency level, that should be documented. When the customer later changes the requirement, the impact can be assessed against the original design instead of reverse-engineering why a component was chosen.

ADRA-0008 and 37611T are the successor design path

Avaya’s 2024 retirement announcement introduced ADRA-0008 Avaya IP Office Platform Design as the replacement direction for midsize design. The new credential is earned through the 37611T Avaya IP Office Design Proficient Test and is issued without a set expiration date under the announcement, subject to future program changes.

That transition should be explicit whenever 37820X is discussed. The old exam is useful for historical search intent and for understanding earlier Avaya midsize architecture, but current candidates should use present-day IP Office design training and current product documentation. A legacy exam-dump listing updated in 2026 does not override Avaya’s retirement notice or prove that the historical code can still be scheduled.

Study design as a chain of justified decisions

The strongest way to use legacy material is to reconstruct design reasoning. For a sample customer, write the requirements, assumptions, constraints, capacity calculations, topology, resiliency model, endpoint strategy, integrations, licensing dependencies, and growth plan. Then challenge each choice: what requirement does it satisfy, and what would change if the requirement changed?

This approach builds a reusable solution-architecture skill while avoiding the trap of memorizing retired product combinations. For credential planning, use Avaya’s current training access points and confirm whether the published ADRA-0008/37611T successor remains the active requirement. The older 37820X page can still teach why communications design is a structured decision process rather than a product catalog exercise.

The successor relationship should also be read as a change in program design. ACDS was a specialist certification label, while ADRA identifies an Avaya Design Readiness Associate path. The credential title, assessment type, and lifecycle have changed along with the product focus. Someone who passed 37820X historically can describe that achievement accurately, but a new learner should not assume that the old blueprint maps line-for-line to 37611T.

IP Office design still rewards careful discovery around sites, trunks, users, endpoints, resiliency, applications, security, and management. What changes over time are the supported releases, cloud options, licensing models, and portfolio integrations. That is why a current designer should keep a living assumptions sheet for every proposal. Each capacity figure or compatibility statement should have a source and version, making it easier to revalidate the design when Avaya updates a product or the customer changes scope.

Architecture reviews are another strong preparation technique. Present a proposed design to a peer and ask them to attack its assumptions: What happens if the WAN fails? Which users need local survivability? What if the contact center doubles? Which dependency has no redundancy? What is the upgrade path? These questions develop design judgment that remains valuable across credential changes and make the old 37820X subject matter useful without relying on obsolete exam status.

A design proposal should also include operational ownership after deployment. Who will administer the system, monitor alarms, manage users, coordinate carrier issues, maintain backups, and approve changes? A technically complete architecture can still disappoint the customer if the operating model is unclear. Midsize organizations may have small IT teams, so simplicity, remote support, and vendor responsibilities can be as important as feature depth.

Security assumptions belong in the design as well. Remote connectivity, SIP trunks, management interfaces, credentials, certificates, firewall rules, and software updates all create control requirements. The old 37820X exam predates parts of today’s threat landscape, so current design practice should supplement any legacy study material with current Avaya hardening and product-security guidance rather than treating historical architecture examples as sufficient.

Documentation quality also affects proposal reuse. A design template should separate customer-specific facts from reusable engineering patterns so later projects do not inherit assumptions accidentally. Site counts, carrier services, codec choices, survivability requirements, contact center capacity, and licensing should be visible as explicit inputs. Reviewers can then challenge the design efficiently and understand which decisions would change if the customer’s requirements change.

A final review should distinguish solution requirements from product preferences. If a customer asks for a named device or feature, verify the business reason and whether the current portfolio satisfies it in a different way. This keeps architecture anchored to outcomes and prevents legacy terminology from forcing an obsolete design pattern into a current proposal.