Context
The client had a working IoT device portal, but it had aged into a drag on delivery. The portal still mattered: it supported device-management workflows the business relied on. But the underlying technology made new work slower, riskier, and harder to reason about.
That is a common failure mode with internal and customer-facing device portals. The system keeps doing its job, so it survives. Then every small product change starts carrying legacy weight.
The brief was not to run a broad modernization program. The brief was narrower: rebuild the portal on newer technology fast enough that the business could keep moving.
Constraints
Four constraints shaped the work.
- Device-management workflows had to remain understandable and usable after the rebuild.
- The legacy portal could not become a long-running rewrite with unclear finish line.
- The new implementation needed to reduce future development drag, not just recreate old screens.
- The delivery window was tight: the core rebuild had to happen in one week.
That forced a deliberate scope decision. The work had to focus on the parts of the portal that carried real operational value, not every historical detail that had accumulated around them.
Approach
NearLunar started by separating essential portal behavior from legacy shape.
The important question was not "what does the old portal contain?" It was "which workflows must the new portal preserve so the client can keep managing devices without carrying the old implementation forward?"
Once that was clear, the rebuild could stay tight. The new portal was built around the active device-management flows, using newer technology and a cleaner implementation path. Scope stayed close to the business need: modernize the portal path that slowed development, without turning the work into a platform redesign.
Rebuild
The one-week timeline only worked because the work avoided theatre.
Instead of treating modernization as a full audit, roadmap, and rewrite, the rebuild focused on the smallest useful version of the portal that could replace the legacy path. Existing behavior was reviewed for operational importance. Core flows were rebuilt first. Anything that did not support device management or future delivery speed was challenged before it entered the new version.
That kept the work practical. The new technology mattered because it made future changes easier. It was not modernization for its own sake.
Outcome
The client moved from a legacy IoT portal to a modernized device-management portal in one week.
The immediate win was speed: a rebuild that could easily have become a drawn-out migration was compressed into a focused delivery window. The longer-term win was removing a source of development drag. Future portal changes no longer had to fight the same legacy surface area before product work could start.
The result was not a speculative rebuild. It was a targeted replacement of the part of the system that had become too slow to change.
When This Pattern Fits
This pattern fits teams with a legacy portal that still works, but now costs too much time whenever the product needs to move.
If the portal is tied to real operations, a blind rewrite is risky. But keeping the old implementation forever creates its own risk. The safer path is to identify the workflows that matter, rebuild around those, and keep the delivery window short enough that modernization does not become the project.