Connect. Secure. Manage.
Network Proof of Concept
Validate a proposed Cisco or Meraki solution in an agreed test environment before making changes to production sites or critical applications.
Devices supported
across the UK
Client locations
supported
Traffic handled
at peak time
Average
response time
Average response is not a resolution time or a contractual guarantee. Support scope and response commitments are agreed for each engagement.
A network proof of concept tests a specific design decision before you commit it to production. MCI builds focused Cisco and Meraki evaluations around the behaviour you need to verify, whether that concerns platform fit, integration, resilience or operational management. The aim is evidence that helps you decide, not a demonstration designed to make every proposed feature look successful.
A proof of concept is particularly useful when documentation alone cannot resolve how several components will behave together in your environment. It is less useful when the requirement remains so broad that nobody can say what a successful result would mean.
A clear requirement
Turn the business need into a practical network scope with visible dependencies.
A controlled delivery
Plan implementation, testing and rollback before production changes begin.
A supportable result
Leave useful records, ownership and escalation routes behind.
Turn uncertainty into a testable question
We begin with the decision the test must support. For example, can the proposed network enforce the required separation while preserving an important application path? Can a branch continue the agreed activities after losing its primary connection? Can the intended management arrangement support your change process?
Each question needs a measurable or observable outcome. “Works well” is too vague. The test should establish what will be observed, under which conditions and what would cause the proposed approach to be rejected or revised.
The scope should also identify what is outside the exercise. A successful authentication test does not establish capacity for an entire estate. A laboratory failover test does not prove the diversity of circuits at a live building. Keeping those distinctions visible prevents the result from being overstated.
Standards & partnerships
Confidence in the team behind your network.
Cisco Partner
Cisco Meraki
Cyber Essentials
Cyber Essentials PlusMCI Network Services is operated by Proxar Ltd. Certifications apply to the certified legal entity and the scope of its certificates. View accreditation information
Build an environment that represents the decision
The test environment should be close enough to the intended deployment to produce useful evidence. Relevant factors may include hardware, software, licences, topology, client types and the behaviour of a connected system.
We record differences between the proof of concept and production. Some are acceptable because they do not affect the question being tested; others limit the conclusion. A virtual or reduced-scale test can still be valuable, provided its limitations are understood.
Production data and live credentials are not assumed to be necessary. Where representative traffic or application access is required, the handling arrangements are agreed with the relevant owner. A technical experiment should not create an avoidable information-security problem.
A useful starting point
Not sure where to start?
Bring the requirement. We will help you define the engineering work.
Test failure behaviour as well as the preferred path
A feature demonstration usually shows the system under favourable conditions. A useful proof of concept also examines the conditions that could change the decision: a missing dependency, an unavailable link, a rejected authentication attempt or a configuration that falls outside the standard pattern.
For Cisco and Meraki integrations, we can include the operational questions that are often left until later. How is a failed change recognised? What evidence is available? Can an engineer identify which platform owns the fault? How is the previous state restored?
These tests are planned rather than improvised. The environment must have a known starting state and a controlled route back, particularly where the exercise connects to shared infrastructure or a provider’s test service.
Different environments. The same care.
Built around the work
your network supports.
Finance, banking and the wider private sector. We start with the systems and people that depend on your connections.
Finance & banking
Market-data paths, routing and provider coordination on clients’ behalf.
Financial-market services ↗Offices & multi-site teams
Reliable access between people, workplaces and business applications.
Office network design ↗Data centres & cloud
Network boundaries, workload connections and operational ownership.
Data centre networks ↗Capture evidence that can be reviewed independently
The result should include the test conditions, configuration or build version, observations and exceptions. Screenshots alone are rarely enough to explain why a test passed. Logs, measurements and a concise account of the method make the result more useful to the people approving the next stage.
Unexpected behaviour is recorded rather than edited out of the demonstration. It may expose a limitation, a design issue or a test-environment problem. The response is to investigate and state the consequence for the decision, not to label every unexpected result a minor anomaly.
Where the proof of concept fails to answer the question, that is also a result. The report should explain whether a revised test, a different architecture or additional evidence is needed.
Use the outcome in design and rollout planning
A successful proof of concept informs the next stage; it does not replace detailed design, site readiness checks or production acceptance. Low-level design captures the settings and dependencies needed to implement the chosen approach consistently.
A pilot deployment can then examine the design in a real operating location before a wider multi-site rollout. That is a different stage from the initial proof of concept, with its own operational responsibilities and acceptance criteria.
The commercial scope should separate preparation, testing, analysis and any follow-up work. Equipment availability, licences and third-party participation may influence both timing and cost, so they are identified before the test programme begins.
Proof-of-concept questions
Do we need a proof of concept for every network project?
No. A straightforward deployment using a well-understood design may not justify one. The exercise is most valuable when it can resolve a material uncertainty that would otherwise affect procurement, architecture or the risk of a production change.
Can we use equipment already in our lab?
Often, provided it represents the relevant parts of the intended solution. We check the model, software and licence position and record any differences. A convenient lab device should not silently stand in for a platform with materially different capabilities.
Will the result include a recommendation?
The findings should explain what the evidence means for the decision. That may be to proceed, revise the proposal or obtain further information. A recommendation is tied to the tested conditions rather than expressed as an unrestricted endorsement of a product.
What should we bring to the initial discussion?
State the decision, the uncertainty and the deadline. Plan a network proof of concept around the question that matters, rather than assembling a large test environment before deciding what it needs to establish.
Talk to a specialist
What does your network need next?
Tell us what you are planning, changing or trying to improve. We will help define a practical next step and the engineering scope.
+44 203 196 6566Choose option 1
sales@proxar.co.ukUK-wide service.
Most of our engineers are based in Kent, with a focus on London, Sussex, Essex and Berkshire.
Existing customers should use their agreed support and escalation channels. This form is for service enquiries, not a monitored emergency ticket.
Tell us what you need.
A short outline is enough. Please do not include passwords or sensitive network details.
Thank you. Your enquiry has been submitted.
Please check your name, email and message, then try again.
Your form session expired. Please try again.
Please wait a minute before sending another enquiry.
We could not submit your enquiry. Please call or email us instead.