Introduction
Sooner or later, every experienced KNX integrator inherits a project that was poorly designed.
Common signs:
- No clear group address logic
- Random naming
- Overloaded lines
- Missing documentation
- Client afraid to touch the system
Migrating such an ETS project is not just a technical task — it is a risk management exercise. One wrong move can break a system that is at least partially working.
This article explains how to safely migrate and improve a poorly designed ETS project, without unnecessary downtime, panic, or blame.
First Rule: Never “Clean Up” a Live System Blindly
A badly designed ETS project may still:
- Be relied on daily by users
- Have hidden dependencies
- Contain undocumented logic
- Mask electrical or network weaknesses
The goal is controlled improvement, not cosmetic perfection.
Step 1: Initial Assessment Before Touching Anything
Before making any changes, answer these questions:
✔ Is the system currently operational?
✔ What functions are critical to daily use?
✔ Is there any documentation at all?
✔ Who originally commissioned the system?
✔ Has the system been expanded over time?
Never assume the ETS project reflects reality.
Step 2: Secure the Existing State
This step is non-negotiable.
Actions
- Create multiple ETS backups
- Export the full project
- Archive all versions
- Label backups clearly with date and site status
If something goes wrong later, rollback must be possible.
Step 3: Compare ETS Project With Physical Reality
Poor projects often drift from reality.
Check
- Actual number of devices vs ETS
- Physical line structure vs topology
- Power supplies and couplers present
- IP routers and network layout
Mismatch here explains many hidden issues.
Step 4: Identify the Core Design Problems
Common design flaws include:
- Single overloaded KNX line
- No separation of control and feedback
- Random group address numbering
- Mixed logic and direct control
- No naming standard
List problems — don’t fix them yet.
Step 5: Decide Migration Strategy (Critical Decision)
There are three safe migration approaches.
Option 1: Minimal Intervention (Stabilise Only)
Used when:
- Client wants zero downtime
- System mostly works
- Risk tolerance is low
Focus:
- Power issues
- Communication stability
- Network fixes
No logic restructuring.
Option 2: Phased Migration (Recommended)
Used when:
- System must improve
- Client accepts staged changes
- Long-term reliability is required
Focus:
- Migrate area by area
- Improve group structure gradually
- Keep old and new logic parallel temporarily
This is the safest professional approach.
Option 3: Full Redesign (Rare, High Risk)
Used when:
- System is fundamentally broken
- Client accepts downtime
- New documentation is mandatory
Only recommended with full client approval.
Step 6: Start With Infrastructure, Not Logic
Always fix foundations first.
Priority Order
1️⃣ Power supply sizing
2️⃣ Line segmentation
3️⃣ IP routing & network stability
4️⃣ Bus voltage consistency
Do not redesign logic on an unstable system.
Step 7: Introduce a New Group Address Strategy Carefully
Never delete old group addresses immediately.
Safe Method
- Create a new structured group address range
- Migrate one function at a time
- Keep legacy addresses temporarily
- Verify behaviour before removal
Parallel operation prevents service disruption.
Step 8: Separate Control and Feedback Properly
Poor projects often mix these.
Migration Approach
- Introduce new feedback group addresses
- Update actuators first
- Update keypads gradually
- Observe behaviour under real use
Feedback fixes alone dramatically improve system feel.
Step 9: Clean Up Naming (But Don’t Break Logic)
Bad naming is annoying — but harmless if logic works.
Rule
- Rename group addresses only after functionality is confirmed
- Never rename and rewire logic at the same time
Clarity comes second to stability.
Step 10: Handle Central Logic With Extreme Care
Logic modules, servers, or visualisation systems often hide dependencies.
Best Practice
- Map logic inputs and outputs
- Document dependencies
- Change one rule at a time
- Test extensively
Central logic failures affect the whole system.
Step 11: Validate Filters After Every Phase
After any migration step:
- Rebuild filter tables
- Download to all couplers and routers
- Verify cross-line communication
Filtering mistakes are a common migration pitfall.
Step 12: Test Like a User, Not Like an Engineer
Do not rely only on ETS tests.
✔ Test from keypads
✔ Test scenes
✔ Test simultaneous actions
✔ Test under load
✔ Test different times of day
Users find problems engineers miss.
Why Poor ETS Projects Exist
Usually due to:
- Time pressure
- No standard templates
- No future planning
- Multiple integrators over time
- Lack of commissioning discipline
Understanding this helps avoid repeating mistakes.
Common Migration Mistakes
❌ Renaming everything at once
❌ Deleting old group addresses early
❌ Changing logic without documentation
❌ Ignoring power and network issues
❌ Working on live systems without rollback
These mistakes often create more problems than they solve.
When to Stop and Redesign Completely
A full redesign may be necessary if:
- Power and topology are fundamentally wrong
- No logic consistency exists
- System is unmaintainable
- Client agrees to downtime
This decision must be explicit and documented.
What Clients Actually Want
Clients rarely ask for:
“Perfect ETS structure”
They want:
- Reliability
- Predictable behaviour
- Easy maintenance
- Confidence in future changes
Migration success is measured in stability, not beauty.
Conclusion
Migrating a poorly designed ETS project is less about programming skill and more about discipline, patience, and risk control.
A professional migration:
- Respects what already works
- Fixes foundations first
- Improves logic gradually
- Documents everything
Done correctly, even the worst ETS projects can become stable, maintainable, and future-ready.
In KNX, how you recover broken systems defines your expertise.
