Circuit board redesign: how can you update your existing product?

When should board redesign be considered?

A component used in your current product may have become difficult to source. You may also need to fit a different enclosure, reduce power consumption or add sensors and interfaces. Sometimes an earlier project arrived with incomplete documentation and repeat production depends on one person. First, identify the differences between the current state and the intended version, then determine whether a limited revision or a new board design is appropriate.

Replacing a single faulty component is different from developing a new manufacturable board version. Redesign can be assessed when production continuity or additional functionality is needed. Very low quantities, limited access to the existing product or extensive testing requirements may affect the economics. Available solutions, limited revisions and new designs are compared against expected life and quantities; development is not automatically the best option for every old board.

Which information should accompany the existing board?

Editable schematics, the PCB project, BOM, source code and programming instructions make the initial assessment easier. Include the board revision, device versions that use it and known problems. Photographs, cable connections, power supply information and mechanical drawings are also useful. A working sample or controlled system access may allow behaviour to be measured. If the information is confidential, we can begin with an NDA.

When sources are missing, their impact is explained from the start. Gerber files alone do not provide the schematic, software and design rationale. A physical board does not describe every function hidden within it. Required behaviour can be documented using information the customer is authorised to provide, and new engineering work can be planned for missing areas. A definitive promise to reproduce every feature is not made before uncertainties are resolved.

• Board and device revision, and existing source files
• Connection list, power and operating environment
• Functions to retain and requested changes
• Expected quantities, working sample and testing facilities

An unavailable component's replacement is not selected by its name alone

Manufacturer product lifecycle information is checked when selecting parts for a new design. Manufacturers such as TI identify active products, products not recommended for new designs and discontinued products. This informs procurement planning but does not guarantee long-term stock. Technical specifications and current availability are reassessed during the project.

Components that appear to have the same package can differ in pin functions, operating voltage, measurement behaviour or control method. Replacing a processor also requires consideration of software migration and peripheral compatibility. Alternatives are assessed for their effect on the schematic, PCB, BOM and testing scope. Installing a cheaper or available component alone does not modernise a board; a validated version meeting the intended functions is needed.

Connector compatibility, board dimensions and machine behaviour are preserved together

If the existing enclosure and cables must be retained, measure the board outline, mounting holes, connector locations and component heights. Using the same connector does not guarantee identical electrical connections; pin functions and voltages must be documented. Communication with sensors, motors, displays and other controllers is also assessed. Bench operation and operation inside the machine require different validation conditions.

For example, a new board in an existing dosing device may need to preserve user settings and communicate with the current display. Compatibility with the old control system must be defined separately when adding communication features. Acceptance criteria include behaviour during power loss, restarts and connection failures. Responsibilities and specialist assessment for any safety-related functions are defined separately; the presence of a new board does not itself prove system conformity.

Clarify software sources and usage rights from the outset

If existing firmware sources and build information are available, their portability is assessed. Without source code, developing new software from an authorised functional description may be a separate scope. Screen flows, record formats, device settings and communication behaviour are defined. Possessing a compiled program does not mean it can be transferred seamlessly to a new processor or edited.

Source code, editable electronics files and technical explanations developed in the new project are defined as deliverables. Documenting the build environment and programming steps makes future versions easier to plan. Library, tool and pre-existing component licences are explained separately to establish how subsequent maintenance and manufacturing can proceed.

Manage the transition through prototypes, pilot use and version records

The first new board is tested against predefined functions. Values and acceptance limits for comparison with the existing system must be clear. A limited pilot deployment may precede wider use, with field findings incorporated into revisions. A sample that works in the first trial and a version prepared for repeat production are different stages. Board and software revisions, test results and approvals are recorded together.

If the new board fits some existing product versions but not others, document that distinction. The manufacturing package specifies which BOM, program and settings to use. To begin with VOMRO, share the reason for the upgrade, existing board information and target volume. Together, we can define confidentiality, assessment scope, prototype acceptance and source delivery, turning a vague request to 'make the same thing' into a measurable development project.