Experience with C#, .NET, SQL and Azure-based architectures would also be beneficial, as the internal direction of travel is towards a more modern and maintainable technology stack.

Initial Systems in Scope

The initial systems identified as suitable for third-party support are:

• Data warehouse-related support
• Data feed application support
• Lead referral system support

These areas have already been subject to internal knowledge transfer, making them the most appropriate starting point for external support as there is existing video & documentation. There may also be a requirement to support elements of the LRG lettings portal feed capability, depending on the outcome of internal discussions regarding whether a separate portal feed system remains necessary.

Portal Feed Context

The existing portal feed capability is currently linked to legacy technologies and dependencies. The team is considering whether this should continue to be maintained in its current form or rewritten into a more modern technology stack that aligns better with the wider internal team’s capability. The future direction may involve moving the portal feed data away from the current data warehouse dependency and into an Azure-based or Data Core-style database model, so that any future feed service is more detached, maintainable and supportable. The rewritten feed system, if progressed, would need to continue supplying property data to the relevant property portals without disrupting their existing integration expectations. The transcript specifically references the need for portals such as Rightmove, Zoopla and OnTheMarket to continue receiving the expected data through the established integration pattern. This would be one of the key projects for the LRG internal team whilst we have BAU cover from a provider.

Current Data Warehouse Dependency

The data warehouse currently supports change detection from the Reapit application, with changes being picked up from Snowflake and then triggering downstream activity into portal feeds and KPI-related processes. There is an internal view that some of these dependencies may be reduced or removed over time, particularly where KPI reporting is being replaced by newer reporting mechanisms. However, the provider should assume that the data warehouse remains an important system in the short term and may require BAU support during the transition period. There is also a need to confirm whether the LPRM system has a dependency on the data warehouse or whether it pulls data directly from Reapit. This should be treated as a discovery item rather than an assumed dependency.

Expected Responsibilities

• Provide flexible development and support capacity for the agreed legacy systems
• Support BAU incidents, defects and minor enhancements across the initial scope with incidents being logged on Freshdesk.
• Work from existing documentation where available
• Engage with internal subject matter experts during onboarding and knowledge transfer
• Help stabilise support demand so internal developers can focus on strategic improvement work
• Identify risks, dependencies and knowledge gaps in the systems being supported
• Provide clear updates on progress, blockers and areas requiring internal input
• Support the team in maintaining service continuity while longer-term modernisation options are assessed

Expected Ways of Working

The provider should be comfortable working collaboratively with the internal Digital Product & Data team, including key technical resources who hold working knowledge of the current systems. The engagement should support a practical transition model, where provider resource begins with systems that already have documentation and knowledge transfer material available, while the internal team continues deeper knowledge transfer and modernisation planning. Where development work is required, this should be managed as a proper delivery activity, with epics, stories, tasks, testing and appropriate technical governance rather than informal ad hoc changes.

Key Outcomes Required

The successful provider engagement should help us achieve the following outcomes:

• Improved BAU support coverage for legacy applications
• Reduced dependency on a small number of internal specialists
• More time for internal knowledge transfer between key team members
• Better understanding of current system dependencies
• Support for a potential transition away from legacy portal feed architecture
• A more sustainable support model by the end of the engagement
• Progress towards reducing dependency on the current data warehouse where appropriate

Important Considerations

This requirement should be treated as flexible at this stage. The precise scope may evolve once we have confirmed the provider’s available skills, cost model and ability to support the required technology stack. The strongest immediate fit is likely to be a provider who can supply experienced PHP, Laravel, MySQL and Linux capability, while also being comfortable working in an environment that is moving towards a more modern Azure-aligned architecture. The provider should understand that this is not just a tactical support arrangement. The desired outcome is to help the internal team get into a stronger position, not simply to temporarily absorb support work before the same risks return once the engagement ends.