A mechanism-based theory of legacy enterprise information system reconfiguration in incumbent firms

The evolution of information systems in the enterprise

The role of EIS in enterprise contexts is evolving. For some time, EIS were considered the transactional backbone that enabled organizations to standardize core enterprise processes such as supply chain management (SCM) (Cao et al., 2022) and enterprise resource planning (ERP) (Gattiker and Goodhue, 2005), thereby supporting enterprise-wide operations (Aral et al., 2024), data management (Lehrer et al., 2018), or organizational control processes (Ross et al., 2006) under increasingly complex and uncertain market conditions (Sambhara et al., 2022). For example, a manufacturing firm may have relied on ERPs like ‘SAP S/4HANA’ to standardize its production, logistics, or financial processes in increasingly competitive global markets.

Today, organizations no longer rely on EIS alone, but manage broader EIS landscapes, which are portfolios of interconnected IS intended to complement the transactional backbone. While an organization’s legacy EIS (e.g., CRM systems) continue to ensure standardization and operational stability, the broader EIS landscape emerges as a locus of enterprise renewal (Lokuge et al., 2025). For example, the same manufacturing firm using ‘SAP S/4HANA’ to standardize its production processes could complement this legacy EIS with ‘Salesforce’ or ‘Amazon Web Services’ to benefit from real-time data insights, to adapt production processes to market changes, or to create novel customer experiences (Mikalef et al., 2021). This shift has important implications for IS research and practice.

IS research increasingly focuses on questions related to EIS landscapes when investigating the evolution of IS in enterprise contexts more broadly (e.g., Sambhara et al., 2022). For example, recent work emphasizes that EIS landscapes must be reconfigured over time rather than treated as ‘one-off’ implementation outcomes (Aral et al., 2024) or ‘final design achievement’ (van Den Hooff et al., 2026). Related contributions investigating ‘digital infrastructure evolution’ suggest that the reconfiguration of digital infrastructures is most effective when stable cores of established systems (e.g., legacy EIS) are incrementally augmented with digital complements (Rodon Modol and Eaton, 2021), while studies on ‘enterprise system evolution’ highlight the importance of path dependency between newly introduced and legacy systems (Hanseth and Lyytinen, 2010). While this literature points to incremental modernization as a potential pathway for organizations seeking to augment their legacy EIS with complementary IS (Haki et al., 2020), the mechanisms with which organizations can reconfigure their legacy EIS in practice have not yet been sufficiently explained, leaving a critical gap in our understanding of EIS evolution (Aral et al., 2024; Beese et al., 2023). At the same time, reconfiguration is only one strategy through which organizations may ‘future proof’ their EIS landscapes. For example, the literature also discusses wholesale replacement of legacy EIS through clean-slate implementations or migration to cloud-native solutions (M’baya et al., 2017; Willcocks et al., 2016), as well as platformization, wherein EIS portfolios are refactored into, or onto, a digital platform that hosts internal modules as well as external complementors (Constantinides et al., 2018; Sebastian et al., 2017). Importantly, each of these strategies envision distinct trajectories for future EIS and rest on different assumptions about the value embedded in an organization’s installed base. Table 1 provides an overview and summary.

OPEN IN VIEWER

Table 1.

Overview of strategies to ‘future proof’ EIS landscapes.

Strategy	Core logic	Typical application area	Representative literature
Wholesale replacement	Retire legacy EIS and substitute with a modern stack through on-site refresh or cloud-native SaaS	Greenfield or digital-native firms; post-M&A consolidation; severe technical obsolescence	Aral et al. (2024); M’baya et al. (2017); Willcocks et al. (2016)
Platformization	Refactor the EIS landscape into (or onto) a digital platform with internal modules and external complementors	Platform-mediated business models with strong network effects; firms positioned to act as platform owners	Constantinides et al. (2018); Nambisan et al. (2017); Sebastian et al. (2017)
Reconfiguration (this study)	Preserve legacy EIS as stable systems of record while progressively augmenting them with complementary IS	Incumbent, asset-intensive B2B firms; high operational, reliability, and compliance requirements; high switching costs; non-substitutable embedded process, data, and control logics	Hanseth and Lyytinen (2010); Henfridsson and Bygstad (2013); Rodon Modol and Eaton (2021); Sebastian et al. (2017)

In practice, ‘future proofing’ EIS landscapes is particularly challenging for incumbent firms (Aryal et al., 2023). These organizations operate within deeply entrenched organizational structures and rely heavily on vendor-controlled EIS, which constrain their ability for system modification (Ross et al., 2019). To mitigate these constraints, incumbent firms typically reassess whether their legacy EIS remain aligned with evolving operational and strategic objectives (Grover and Lyytinen, 2023). Whenever this is not the case, legacy EIS are considered sources of technical debt (Avgeriou et al., 2025) that should ideally be replaced (e.g., Rinta-Kahila et al., 2023). Yet, such ‘clean-slate’ replacements are often misaligned with ongoing operations (Hanseth and Lyytinen, 2010). This creates persistent tensions between legacy EIS constraints and ambitions for enterprise transformation, and positions technical debt as a central construct for investigating the evolution of IS in enterprise settings more broadly. In what follows, we explore the intersection of EIS and technical debt in more detail.

Enterprise information systems and technical debt

The technical debt concept originated in software engineering (Cunningham, 1992) but has since been adopted in IS research, where it has been conceptualized as suboptimal technical or organizational decisions that accrue over time, and that subsequently increase the cost, effort, or risk of future technological change (Kruchten et al., 2012; Rolland et al., 2018). For example, manifestations of technical debt in EIS contexts can include code-level debt (Li et al., 2015), which undermines future maintainability (Ramasubbu and Kemerer, 2016); architecture debt (Kruchten et al., 2012), which emerges when tightly coupled software components, interfaces, or EIS extensions make future change costly or risky (Rolland and Lyytinen, 2021); and data and analytics debt (Rolland et al., 2018), which develops when fragmented data structures or poor data governance reduce the reliability and scalability of data-driven EIS (Sculley et al., 2015). Table 2 synthesizes the concept.

OPEN IN VIEWER

Table 2.

Concepts, antecedents, and consequences of technical debt and legacy EIS.

Concept	Definition	Antecedents	Consequences	References
Technical debt	Future cost arising from short-term design choices that compromise long-term EIS performance	• Budget pressure • Workarounds • Deferred fixes	• High maintenance effort • Slow system change • Low performance	Kruchten et al. (2012); Rolland et al. (2018); Rinta-Kahila et al. (2023)
Code-level debt	Code-level deficiencies that hinder future EIS modifications	• Quick fixes • Weak coding standards • Limited testing	• More defects • Lower developer productivity	Li et al. (2015); Ramasubbu and Kemerer (2016)
Architecture debt	High-level design flaws that make future EIS-wide changes costly or risky	• Partial or delayed replacements • Patching monoliths	• Rigid EIS • High cost and risk of upgrades • Dependencies	Kruchten et al. (2012); Rolland and Lyytinen (2021)
Data/analytics/ML debt	Data and model shortcuts that reduce the reliability and scalability of EIS analytics	• Inconsistent data structures • Weak data governance	• Unreliable insights • Costly rework at scale • Lower long-term analytical value	Rolland et al. (2018); Sculley et al. (2015)
Intentional vs. unintentional debt	Planned shortcuts for speed vs. accidental problems from errors or weak processes	• Intentional: Time-to-market choices • Unintentional: Skill gaps; process drift	• Manageable if tracked and serviced; harmful if invisible	Yli-Huumo et al. (2014); Ghanbari et al. (2025)

IS research has investigated the role, implications, and management of technical debt (e.g., Ampatzoglou et al., 2015; Magnusson et al., 2018). Indeed, this literature provides many valuable insights related to technical debt as it relates to the codebase (Li et al., 2015), enterprise architecture (Kruchten et al., 2012), and specific functionalities (Sculley et al., 2015) of legacy EIS (e.g., Banker et al., 2021). However, we also observe a critical tension in this literature, wherein legacy EIS are simultaneously conceptualized as liabilities when unmanaged and as assets when effectively controlled.

One dominant literature stream considers legacy EIS as sources of technical debt (e.g., Banker et al., 2021; Fürstenau et al., 2019; Rinta-Kahila et al., 2023), resulting in organizational inflexibility (Banker et al., 2021), increased maintenance costs (Ramasubbu and Kemerer, 2016), or the inability to adopt new digital technologies (Fürstenau et al., 2019). However, equating legacy EIS with technical debt constitutes an analytical oversimplification, since legacy EIS do not inherently represent technical debt per se; rather, technical debt emerges in relation to how legacy EIS are developed, extended, and embedded in organizational contexts. Technical debt, therefore, is one outcome of complex socio-technical processes that may be intentional (Yli-Huumo et al., 2014) – for example, to enable rapid experimentation (Brown et al., 2010) – or unintentional (Klinger et al., 2011) – for example, arising from coordination breakdowns. Put differently, while legacy EIS themselves are not technical debt in every instance, the ways in which these systems are extended, modified, or embedded can create liabilities (Rolland et al., 2018). These liabilities, in turn, may result in diminished organizational performance (Rolland et al., 2018), increased cost (Rolland and Lyytinen, 2021), or reduced staff productivity (Ramasubbu and Kemerer, 2016).

A second literature stream draws on Hanseth and Lyytinen’s (2010) installed base perspective to frame legacy EIS not as technical debt, but as generative infrastructures, arguing they may represent assets, as potentially untapped sources of future enterprise transformation (Avgeriou et al., 2016; De Cuyper et al., 2020; Leiting et al., 2022; Sutcliff et al., 2019). This work builds on earlier IS contributions showing how firms intentionally accumulate technical debt, for example by deliberately postponing costly replacements to prioritize rapid market responsiveness (Brown et al., 2010) or by retaining legacy EIS while incrementally modernizing their EIS landscape through APIs, microservices, or cloud extensions (Sebastian et al., 2017). More recent work argues that legacy EIS embody stable transaction logics, standardized processes, or historical datasets, which may be leveraged to foster organizational renewal (Lokuge et al., 2025). As such, legacy EIS can serve as a much-needed foundation for “digital reinvention” (Sutcliff et al., 2019: 4), an argument echoed by De Cuyper et al. (2020) and Leiting et al. (2022), who suggest legacy EIS may be ‘reconfigured’ – a process involving the merger or extension of current capabilities with emerging digital technologies. This view contrasts starkly with prior work that adopts a technical debt perspective and advocates for large-scale system overhauls, such as replacing legacy EIS with cloud alternatives (M’baya et al., 2017) or shifting them to external providers (Willcocks et al., 2016).

Ultimately, the unresolved tension between legacy EIS as a liability versus asset in the IS literature motivated us to explore the changing role of EIS in enterprise contexts by asking how incumbent firms reconfigure their installed base of legacy EIS for enterprise renewal.

Design capital as an analytical lens to explore legacy EIS reconfiguration

To capture and describe how incumbent firms reconfigure their installed base of legacy EIS for enterprise renewal, we draw on Woodard et al.’s (2013) design capital framework as our analytical lens. This framework offers a well-established vocabulary for theorizing how digital resources are mobilized under technical debt constraints and has increasingly been applied in IS research to study technical debt at the organizational level. Prior studies, for example, used Woodard et al.’s (2013) design capital framework to examine the effects of technical debt on enterprise software reliability (Ramasubbu and Kemerer, 2016), its implications for firm performance (Banker et al., 2021), or the dynamics of legacy IS discontinuation (Rinta-Kahila et al., 2023). Building on this precedent, we here use Woodard et al.’s (2013) constructs to investigate legacy EIS reconfiguration as follows:

First, following Woodard et al. (2013), we conceptualize technical debt as socio-technical obligations that increase the effort, cost, or risk of modifying an existing IS. In the context of legacy EIS, such obligations may manifest as rigid architectures that resist extension, fragmented data structures that impede analytics, or governance arrangements that complicate modification (e.g., Kruchten et al., 2012). This conceptualization of technical debt is important because we do not equate legacy EIS with technical debt per se; rather, we conceptualize technical debt as accumulating within and around legacy EIS as they evolve over time.

Second, Woodard et al. (2013) conceptualize design capital as the cumulative stock of reusable assets embedded in the IS that are available to an organization. We thus refer to EIS capital as the cumulative stock of reusable assets embedded in the installed base of legacy EIS, including standardized process logics, historically accumulated and organizationally validated data, and established control structures, and the organizational knowledge associated with legacy EIS use and governance.

Third, Woodard et al. (2013) define option value as the range of possible future initiatives (e.g., the development of a new digital market offering) that an organization’s design capital can support at acceptable cost and risk. Accordingly, we conceptualize EIS option value as the extent to which an installed base of legacy EIS enables reconfiguration.

Finally, we draw on Woodard et al.’s (2013) notion of design moves to capture the specific actions through which organizational actors reconfigure their installed base of legacy EIS for enterprise renewal. Each design move may expand or constrain the EIS capital, alter the range of feasible digital initiatives, and, in turn, increase, contain, or reduce technical debt. Table 3 summarizes how we adapt each of Woodard et al.’s (2013) constructs to legacy EIS.

OPEN IN VIEWER

Table 3.

Construct comparison table.

Construct	Woodard et al. (2013)	Application in this study
Technical debt	The expected cost or effort entailed in exercising the options embedded in a firm’s design capital. Accumulated through design shortcuts and deferred architectural decisions.	Socio-technical obligations that increase the effort, cost, or risk of modifying a legacy EIS. Not equated with legacy EIS but understood as a condition that accumulates within and around them.
Design capital → EIS capital	The cumulative stock of designs owned or controlled by a firm. Includes software components, interfaces, data structures, and other digital artifacts that enable innovation.	EIS Capital: The reusable assets embedded in the installed base of legacy EIS.
Option value → EIS option value	The range of alternative designs that the current stock makes possible, reflecting both present functionality and future development possibilities.	EIS Option Value: The extent to which the current installed base of legacy EIS affords further reconfiguration at acceptable cost and risk.
Design moves	Discrete strategic actions that enlarge, reduce, or modify a firm’s stock of designs, thereby altering its option-value/technical-debt profile.	Discernible reconfiguration actions through which organizational actors reconfigure the installed base of legacy EIS, simultaneously affecting EIS capital, EIS option value, and technical debt.
Unit of analysis	Individual digital artifacts (products, platforms, software systems) and design-based competitive actions of individual firms.	The installed base of legacy EIS, and the organizational arrangements governing their evolution over time.

Research design

We selected a research design that enables us to explore, explain, and build theory from the phenomenon of legacy EIS reconfiguration. Multiple case studies are considered especially suitable for this purpose (Eisenhardt, 1989; Yin, 2015) as they allow us to examine variations in legacy EIS reconfigurations across different organizational contexts. We furthermore employ Bygstad et al.’s (2016) mechanism-based theorizing approach. Consistent with other IS studies pursuing mechanism-based theorizing in case research (e.g., Henfridsson and Bygstad, 2013; Lehmann et al., 2022; Stohr et al., 2024), our research thereby intends to identify generative mechanisms – “the causal structures that may or may not be activated in order to produce a certain ‘outcome’” (Øvrelid and Bygstad, 2019) and explain “how the cause produces its effects by describing the process by which this happens” (Ylikoski, 2019: 16). Specifically, generative mechanisms explain the causal paths (Sayer, 1992) with which incumbent firms reconfigure their installed base of legacy EIS for enterprise renewal, the contextual factors underpinning this process, and the outcomes thereof (Ylikoski, 2019). Conversely, research designs like variance-based quantitative work (Mohr, 1982) would have required stable, comparable constructs and large-sample measurement over time, which would have been difficult given the path-dependent and heterogeneous character of EIS reconfiguration trajectories. Similarly, a purely interpretive qualitative approach (Klein and Myers, 1999; Walsham, 1995) would foreground meanings and sensemaking but would not, by itself prioritize the causal process explanation that is central to our study, and mixed methods (Venkatesh et al., 2013) would be better suited for subsequent testing once mechanisms have been specified.

Case selection

We selected cases through criterion-based theoretical sampling – that is, the deliberate inclusion of research settings that meet specific theoretical or empirical criteria relevant to the phenomenon under investigation (Yin, 2015). We ensured that all cases (1) were comparable; (2) sufficiently represented legacy EIS reconfiguration as our phenomenon under investigation, and (3) provided empirical access. Indeed, the analytical, rather than statistical, generalizability of multiple case studies follows a replication logic in which each additional case either confirms or extends emerging theoretical insights, and each case “serves as a distinct experiment that stands on its own as an analytical unit” (Eisenhardt and Graebner, 2007: 25). A case protocol (Yin, 2015) helped us structure our criterion-based theoretical sampling process:

First, to ensure all cases were comparable and that our phenomenon of interest was observable, the empirical setting had to be deliberately bound – an inevitable trade-off between generality and specificity (Weick, 1979). We therefore identified incumbent firms within the German manufacturing sector, a context where legacy EIS reconfiguration is especially visible. Specifically, German manufacturing incumbents have operated consistently for multiple generations (Carroll and Hannan, 2000), experience long product life cycles measured in decades, serve export-oriented B2B customers with stringent reliability and compliance requirements, and sustain vertically integrated industrial operations (Porter, 1985). Many exhibit governance characteristics associated with the German “Mittelstand” tradition, including specialized market positions, continuity-oriented family ownership, and strong regional embedding, which creates a comparatively conservative organizational culture that favors incremental rather than disruptive change. Consequently, in this setting, legacy EIS reconfiguration emerges as the dominant mode of enterprise transformation, making the underlying mechanisms observable.

Second, we aimed to identify incumbent firms who successfully reconfigured their legacy EIS over time. We defined success as instances wherein the installed base of legacy EIS remained operational as the incumbent firm’s transactional backbone (that is, no ‘rip-and-replace’ occurred) and wherein the incumbent firm had pursued a reconfiguration trajectory that culminated in an operational EIS landscape that facilitated the incumbent’s enterprise renewal objectives – for example, by creating new digital offerings, servicing existing operations more efficiently, or generating new revenue streams. Incorporating successful instances of EIS reconfiguration was desirable because incumbent firms who succeeded in this process likely overcame challenges in doing so, and participants would therefore be able to explain how they accomplished it. This would, in turn, enable us to delineate effective managerial guidelines.

Third, Eisenhardt and Graebner (2007) argue that a retrospective approach enhances the analytic insights of any case study as it allows researchers to include more informants, investigate a phenomenon holistically, and make individual cases comparable regarding time. Completion of the EIS reconfiguration process was therefore our third sampling criterion. Finally, for practical feasibility, we engaged only with incumbent firms where participants would be willing and able to participate in data collection. We initially identified 15 potentially suitable cases and, after being able to meet with representatives of eight German incumbent firms, included five of these as cases in our study. Table 4 provides an overview of each incumbent firm; Table 5 summarizes their installed base of legacy EIS; Appendix A provides detailed case summaries and contextual information for each German incumbent manufacturing firm in our study. Appendix B provides the foundation for Bygstad et al.’s (2016) mechanism-based theorizing approach by highlighting critical events of each incumbent firm’s legacy EIS reconfiguration trajectory over time.

OPEN IN VIEWER

Table 4.

Case overview.

Description	Cases
	Agritech	Printech	Drivetech	Lasertech	Foodtech
Employees	6800	9800	2,800	16,500	18,100
Company age	150 years	150 years	75 years	100 years	100 years
Revenues	$6 bn (2021)	$2 bn (2021)	$0.5 bn (2021)	$4 bn	$5 bn (2021)
Industry	Agricultural machinery	Printing and post-press machinery	Servo systems, gearboxes, motors	Laser cutting and welding machinery	Food processing equipment
# Informants	5	6	6	8	7
Type of informants	Senior manager (1), middle manager (1), project manager (1), external partners (2)	Senior manager (2), middle manager (1), project manager (2), external partners (1)	Senior manager (1), middle manager (0), project manager (2), external partners (3)	Senior manager (1), middle manager (2), project manager (5), external partners (0)	Senior manager (2), middle manager (1), project manager (2), external partners (2)
Initial digital offerings	2011	2008	2018	2016	2019
Digital market offering at time of data collection	Remote diagnostic platform for agricultural machinery	Customer portal offering pay-per-unit subscription; consumables management; maintenance services	Smart gearbox with sensing and smart services to monitor machine performance and predict maintenance	Remote operation services and control center enabling equipment-as-a-service (EaaS)	Remote monitoring; ML-based anomaly detection; advisory services

OPEN IN VIEWER

Table 5.

Overview of legacy EIS across cases.

Case	Available legacy EIS	EIS challenges	EIS strengths
Agritech	• In-house dealer management systems • ERP systems • Telematics on most production equipment • Various EIS to provide customer service	• Telematics data mainly used for ad hoc troubleshooting • Most workflows performed manually	• ERP and dealer systems stable with clear service and warranty processes • Telematics hardware standardized
Foodtech	• ERP and production systems • Custom dashboards • Sensors connected to production equipment but not integrated with ERP systems	• Data spread across many systems and formats • Sensor data not integrated • EIS hard to scale	• Valuable process and production data available in existing systems • Data pipelines and analytics skills emerging in a central organizational unit
Lasertech	• On-premise shopfloor and service systems • ERP tools to support sales and customer service • Some remote access to customer machinery	• EIS are machine and site-specific • Low transparency across EIS landscape • Customer service remains reactive	• Large number of connected-ready production equipment available • ERP and service structures established for billing, warranties, and contracts • Strong service know-how.
Printech	• SAP ERP • E-commerce shop • Workflow management systems • Early remote-service modules and VMI solution	• Fragmented workflows and data flows • EIS run on older in-house software and are hard to modify	• Mature ERP and service processes • Some organizational experiences with cloud and remote EIS
Drivetech	• ERP systems for manufacturing • Sensors in gearboxes support OEM • Some data-driven services	• Proprietary protocols and point-to-point links make integration costly • Sensor log data available but not systematically analyzed or linked to ERP	• Gearboxes equipped with sensors available at customer-sites • ERP master data for products and customers reliable • OEM relationships and joint development projects emerging

Data collection

We collected primary data through semi-structured interviews with 32 key informants. These include EIS users and managers across roles described to us as senior executive, project manager, middle manager, or external partners involved in the management of legacy EIS. Specifically, we followed Merriam and Tisdell’s (2016) advice to select participants able to provide “specialty rather than average opinion” (2016: 96) and recruited individuals “from different hierarchical levels, functional areas, groups […] who view the focal phenomenon from diverse perspectives” (Eisenhardt and Graebner, 2007: 28). Appendix C provides an overview of our informants.

Each semi-structured interview took place face-to-face, lasted approximately 60 minutes, and was audio recorded. Interviews focused on the historical evolution of each incumbent’s EIS landscape, decision-making and governance around legacy EIS, challenges encountered during reconfiguration, sector-specific constraints, and participants’ assessments of the outcome of their EIS reconfiguration journey. We used a common interview protocol developed from relevant literature (Rubin and Rubin, 2011), but avoided academic terminology so that participants could express ideas freely and articulate experiences in their own terms (Coviello, 2005; Myers and Newman, 2007). Consistent with Eisenhardt (1989), we asked each informant the same core questions but iteratively refined follow-up questions as new insights emerged. All interview recordings were transcribed verbatim. Our interview protocol is available in Appendix D.

We also collected 1300 pages of secondary data in the form of field notes, case-documentation, archival documents (e.g., corporate regulatory filings and reports), industry whitepapers, and press releases. Utilizing multiple sources of evidence was appropriate given our intent to build theory (Eisenhardt, 1989) and given the multiple case study method (Yin, 2015). We used the secondary data to document and track the progression of key events that took place within our case organizations (e.g., the critical events indicated in Appendix B) and to corroborate their timing and the descriptions discussed in interviews. For example, product and service descriptions from Foodtech’s website and announcements in an external industry newsletter helped us document the introduction and evolution of enterprise-wide digital offerings referenced by interviewees, here indicated as critical events F10 and F13 in Appendix B. We ceased all interviewing and secondary data collection once additional data no longer generated substantively new insights (Merriam and Tisdell, 2016).

Data analysis

Our data analysis aimed to uncover the generative mechanisms through which incumbent firms reconfigured their legacy EIS. To do so, we followed Bygstad et al.’s (2016) mechanism-based theorizing procedure, iterating through seven steps: (1) constructing event histories, (2) mapping socio-technical structures, (3) abductively re-describing the phenomenon using Woodard et al. (2013) as our analytical lens, (4) inferring affordances and constraints, (5) analyzing design moves (retroduction), (6) composing mechanisms, and (7) validating them across cases. Throughout this process, and in line with Bygstad et al. (2016), we iterated between within-case and cross-case analysis, gradually moving from descriptive narratives to explanatory mechanisms. Table 6 summarizes these steps before we explain each step of our mechanism-based theorizing procedure.

Step 1: Identify critical events. We constructed detailed event histories for each case to anchor our mechanism discovery in transparent accounts of how legacy EIS and EIS landscapes evolved (Bygstad et al., 2016). We identified critical events, such as the launch of new digital offerings or changes to IT governance, using interview transcripts and corroborated the timing and descriptions using secondary data. For each event, we noted triggering conditions, focal actions, and resulting consequences for legacy EIS. We also noted the wider organizational and market context, to support later causal reasoning. Step 1 of our analysis culminated in case-level timelines and event tables (e.g., A1–A13, P1–P15), which we depict in Appendix B.

OPEN IN VIEWER

Table 6.

Data analysis procedure underlying mechanism-based theorizing (adapted from Bygstad et al., 2016).

Step	Explanation	Implemented in this study	References
1. Identify critical events	Develop case-level timelines of critical events that shaped the phenomenon; distinguish periods of incremental vs. more disruptive change and code their antecedents and outcomes.	We constructed detailed event histories for each case, coding triggers, key decisions regarding legacy EIS, and subsequent consequences. As a heuristic, we noted whether events primarily affected everyday use, system design, or the broader organizational context to support later causal analysis.	Bygstad et al. (2016); Lyytinen and Newman (2008)
2. Map socio-technical structures	Identify key actors, technologies, processes, and environmental conditions that form the socio-technical context in which actions are possible and meaningful.	For each case, we mapped the legacy EIS landscape (core systems, integrations, data stores), governance structures (roles, committees, units), partner ecosystems, and salient external constraints (e.g., regulation, market expectations) to enable later causal analyses.	Bygstad et al. (2016); Wynn and Williams (2012)
3. Abductively re-describe the phenomenon	Re-interpret the cases analytically using sensitizing concepts that clarify what is being studied and why it matters.	We abductively re-described legacy EIS reconfiguration as the management of design capital, using Woodard et al.’s (2013) constructs as our analytical lens. We interpreted each case as a trajectory of design choices that increased or decreased technical debt and reshaped EIS capital and EIS option value.	Woodard et al. (2013); Bygstad et al. (2016)
4. Infer affordances and constraints	Use the critical event histories to infer candidate causal mechanisms by examining immediate outcomes, socio-technical interactions, and conditions that enable or constrain them.	For each cluster of related events, we identified immediate outcomes (e.g., improved data access), analyzed socio-technical interactions, proposed candidate affordances (e.g., usage-based billing), and constraints (e.g., data quality issues).	Bygstad et al. (2016)
5. Analyze design moves (retroduction)	Treat each meaningful change as a design move and trace its temporal and causal effects, including how it affects technical debt, capital, and option value over time.	We catalogued discrete architectural and governance changes (e.g., consolidating data platforms) as design moves. For each move, we coded its effect on technical debt (e.g., containing integration debt), on EIS capital (e.g., stabilizing master data), and on EIS option value (e.g., enabling new services or revenue models), and related these to Woodard et al.’s (2013) design capital states.	Bygstad et al. (2016); Woodard et al. (2013)
6. Compose mechanisms	Integrate insights across events, affordances, and design moves into higher-level explanatory mechanisms.	We integrated event sequences, affordance analyses, and design move trajectories to propose candidate mechanisms, analyzing their activation conditions and typical behavioral tendencies.	Bygstad et al. (2016)
7. Validate mechanisms	Test mechanisms against the data using process tracing, cross-case comparison, and searches for disconfirming evidence. Refine the mechanisms accordingly.	We iteratively tested and refined our mechanisms against each case, actively seeking disconfirming evidence, and comparing across all five cases until the mechanisms consistently explained the empirical patterns.	Bygstad et al. (2016)

Leveraging operational EIS stability for digital pilots

The first generative mechanism (M1) that we identified describes how incumbent firms leveraged the operational stability embedded in their legacy EIS – that is, the reliability of established processes, billing routines, system interfaces, and user familiarity that had accumulated over decades of uninterrupted operation – to initiate new digital pilot projects that would have otherwise been unfeasible. Vignette 1 contextualizes M1 using the case of Foodtech, while Table 8 provides empirical examples for each of our five incumbent firms. We describe the specific context, the design moves, and outcomes for M1 as follows.

Vignette 1. Foodtech

Foodtech described its first digital pilots as ‘lighthouse projects’. These self-contained, time-bound experiments relied entirely on the operational stability of its existing installed base of legacy EIS and were run by its new digital division that operated as a ‘corporate startup’. As such, this division could draw on established customer relationships, proven service processes, and existing machinery from within Foodtech. As the Chief Digital Officer described, the key advantage was “immediate customer access. I can travel to any country, interview customers, identify customer problems, and find my pilot customers in the established market” (I_26).

Each lighthouse project was set up “to try out, develop, and test things” (I_29). One such pilot involved the development of a new condition monitoring system for industrial centrifuges used in food production. Rather than purchasing or building new EIS infrastructure to facilitate this project, the team instead chose to build on what was already there: “our machines are of course equipped with sensors that are needed for machine control. In the first step we did not focus on new sensor hardware; rather, we thought: let’s try to use what we already have” (I_28). The resulting condition monitoring system was a simple, minimum viable product: “a manually triggered system” with “a one-to-one relationship between machine and [user]” (I_28) – and underpinned by existing service-level agreements the team adapted from established service contracts. To keep the scope of the project manageable, Foodtech’s digital division engaged only with a small group of pilot customers under NDA, “where you can test out an idea before scaling” (I_26). The first iterations of each lighthouse project were what the team described as “low-hanging fruits”, such as simple dashboards that presented existing machine data so customers “can immediately see how their machine is running, where there are improvement potentials, or where there are problems” (I_28). However, by validating these ‘lighthouse projects’, Foodtech was able to gradually expand these with more advanced capabilities like anomaly detection. As such, the operational stability of legacy EIS infrastructure, including its sensors, processes, or customer relationships, served as a critical foundation on which digital pilots could be built, tested, and refined without disrupting core operations.

Context

All incumbent firms faced a distinct challenge. Their customers no longer wanted to merely purchase the industrial machines each incumbent had produced and relied on for decades as source of revenue. Instead, customers increasingly requested complementary service offerings like predictive maintenance, connected support, or inventory automation. Our participants further recognized that creating and delivering such services would require significant changes to their legacy EIS, which included ERP, SCM or CRM systems but also highly customized shop-floor production systems. Indeed, one of Agritech’s managers emphasized that even minor modifications to legacy EIS would risk disrupting invoicing processes, delay deliveries, or could interfere with production control: “someone comes along and says, let’s shake it [legacy EIS] up – let’s flip it on its head. It’s disruptive and scary […] it is risky [for us]” (I_05, Agritech). Consequently, early proposals to ‘rip and replace’ legacy EIS failed to pass internal approval processes, as they were ultimately perceived to carry high operational risk without demonstrable short-term benefits. At the same time, the incumbent firms had limited experience using then-emerging technologies such as cloud platforms or embedded analytics, which were considered a prerequisite to create the digital service offerings customers requested. Consequently, each incumbent firm needed to find novel ways to leverage their existing legacy EIS, in ways that would preserve their operational stability, while also allowing for digital pilot projects to experiment with new digital service offerings. One manager explained, “we don’t want to completely overturn this [legacy EIS], but slowly enrich it” (I_29, Foodtech).

Context

Across all cases, the incumbent firms recognized that accumulated data (e.g., service logs, sensor readings, production records) were underused but potentially valuable. However, concerns regarding data quality, inconsistent data coding conventions, or fragmented legacy EIS storing this data raised doubts about whether these records were suitable for predictive analytics applications. The key challenge was therefore aligning existing data with potential analytics capabilities within the complex socio-technical constraints imposed by each incumbent firm’s suite of legacy EIS: “We’re still surprised what data we have and how we can use it – even after 15 years” (I_07, Printech).

Design moves

Table 7 depicts the design moves through which the incumbent firms layered analytics onto historical EIS data. This involved first consolidating data from disparate legacy EIS systems by standardizing key identifiers, data structures, and formats, thereby enabling historical records to be read and queried across previously isolated silos. For example, Foodtech “built a data architecture to store data in Azure […] as foundation for analysis” (I_28, Foodtech), Lasertech developed a Data Integration Platform that “unites previously separated databases” from different protocols (I_18, Lasertech), while Printech had been collecting data “since 2000” across “around 3000 sensors” per printing machine, with “over 13,000 machines connected” (I_06, Printech).

A second design move involved introducing data governance roles to manage data quality, access, and stewardship. Within each incumbent firm, dedicated analytics teams coordinated access to shared datasets, resolved inconsistencies, and mediated between domain experts and data scientists. At Agritech, this took the form of institutionalized “machine health teams” in every factory, composed of “data scientists, data engineers, system engineers, product development engineers” (I_01, Agritech), who were responsible for developing and maintaining product-specific analytics models.

A third design move focused on developing and testing analytical models, such as anomaly detection, benchmarking, or recommendation systems, which were iteratively validated with domain experts. Lasertech, for example, described this as “a test and learning phase, where customers pay for participation” (I_18, Lasertech). Finally, these analytics capabilities were integrated into operational tools, including dashboards or remote-operation workflows. For example, Printech’s Performance Advisor identified that a customer needed “20% more setup time” than comparable installations before recommending adjustments (I_06, Printech). Drivetech’s dashboards combined supplier and OEM data (D7), while Foodtech streamed process data to visualize previously unrecognized performance patterns (F7, F8).

Outcomes

Layering analytics on historical EIS data transformed historically accumulated records of data into analytically usable EIS capital. Instead of re-instrumenting their installed base of legacy EIS, the incumbent firms drew on existing log data, sensor readings, or workflow traces to develop new analytics offerings, thus creating strategic options for new data-driven services. In this process, legacy EIS shifted from being primarily systems of record to active sources of operational insight, while newly introduced analytics capabilities enabled rapid experimentation and iterative refinement.

Making historical data analytically accessible exposed gaps and inconsistencies in underlying datasets. For example, missing values, ambiguous identifiers, or uneven data coverage became visible when data were consolidated and analyzed across previously disconnected silos. At Printech, for example, machine sensor data and workflow software collected performance metrics independently, which forced the firm to resolve which source to trust: “sometimes the same data is collected once from the machine and once from the software. Which data do we take?” (I_09, Printech). This challenge ultimately triggered data governance efforts, allowing incumbent firms to incrementally reduce accumulated data debt while improving their analytics capabilities.

Finally, by layering analytics capabilities onto legacy systems, our incumbent firms introduced new predictive and advisory services without disrupting core operations. These services also strengthened the link between legacy EIS and day-to-day decision-making – for example, by embedding recommendations into production workflows. Ultimately, the range of feasible data-driven initiatives expanded, thereby increasing EIS option value.

Context

Each incumbent firm attempted to scale digital services (e.g., after completion of M1). However, new limitations in their legacy EIS emerged. For example, delivering services like connected support, remote monitoring, or use-based subscriptions required incumbents to connect their legacy EIS to those operated by external partners or customers, adapt underlying processes, and exchange data across organizational boundaries. However, the incumbent’s legacy EIS were not designed for this purpose. Replacing legacy EIS was, once again, not a viable option. At the same time, attempts to create ad hoc interfaces between legacy EIS and EIS operated by external partners increased system complexity, thus effectively deepening architectural debt. Faced with this dilemma, each incumbent firm sought alternative approaches to scale their digital service capabilities, while protecting the operational stability of their legacy EIS. As one Printech manager explained: “what do we have? And how can we leverage it?” (I_06, Printech).

Design moves

Augmenting legacy EIS with middleware interfaces began by decoupling operationally stable legacy EIS domains (e.g., Finance, ERP) from fast-evolving areas requiring rapid change (e.g., analytics, customer-facing services). At Printech, this design move was enacted by introducing a unified customer portal with “one portal, one login” (I_10, Printech) that connected to the underlying legacy systems via APIs, allowing the firm to develop new service functions “only in the cloud” (I_10, Printech) without modifying core legacy EIS. Similarly, Drivetech adopted an industry communication standard and a service portal as a “landing page for every product” (I_12, Drivetech), thus effectively creating an interface layer between customer interaction and underlying legacy systems.

Second, incumbents built standardized middleware components that mediated interactions between new digital services and legacy EIS. These middleware components (e.g., API gateways), provided standardized interfaces through which data and functionalities could be accessed without modifying legacy EIS systems. For example, Agritech’s telematics infrastructure generated performance data from farming machines that its dealers could not access directly because the data was locked inside legacy diagnostic systems. Rather than replacing these legacy systems, Agritech built cloud-based delivery layers between its legacy diagnostic systems and dealer-facing applications that exposed selected telematics data through standardized APIs. A data-consent middleware governed which data could be forwarded to dealers for service delivery versus retained internally for product improvement, ensuring that dealers could access actionable machine insights without direct access to underlying legacy systems. This allowed Agritech to package its services under a common brand – “We are using a common brand for these services, called [brand name]; you will find different packages: select, premium, ultimate” (I_01, Agritech) – without altering the underlying telematics systems.

Third, incumbents standardized cross-cutting middleware functionalities, such as user authentication and billing interfaces, that multiple digital services relied on. This design move reduced the need for individual legacy EIS to be integrated with each newly introduced service offering. At Foodtech, a single identity and access management layer replaced five previously disconnected login systems, giving customers access to dashboards and machine monitoring tools via a single-entry point (I_28, Foodtech). Conversely, Lasertech modularized connectivity, security, and billing logics into individual middleware components. In doing so, every new service that the firm introduced could reuse these middleware interfaces, which the firm called “reusable capabilities” (I_21, Lasertech).

Outcomes

By augmenting their legacy EIS with middleware interfaces, the incumbent firms created an ambidextrous EIS landscape wherein legacy EIS could continue to function as stable systems of record, while other digital technologies (e.g., platforms) enabled the delivery of new service offerings at scale. Indeed, exposing their legacy EIS through middleware interfaces (e.g., APIs, shared identity services), these systems became accessible and reusable, thus effectively increasing EIS capital. Furthermore, augmenting legacy EIS with middleware interfaces reduced the need to modify legacy EIS, which minimized architecture debt. Finally, by decoupling the development of new services from transaction processing in legacy EIS, the incumbent firms reduced technical and operational risk, consequently expanding their EIS option value, as the resulting EIS landscape could support a broader range of future digital service initiatives at lower cost and risk. As one Lasertech R&D director reflected, “once you have a reusable, capability-based infrastructure, you suddenly get emergent behavior – someone who would never have done this before suddenly develops on an edge device where he only needs to write a little software, because he doesn’t have to worry about identity management or connectivity” (I_21, Lasertech).

Theoretical implications

Our theoretical contribution consists of an empirically grounded, mechanism-based theory of legacy EIS reconfiguration, which explains how incumbent firms reconfigure installed bases of legacy EIS into EIS landscapes that preserve operational stability while simultaneously facilitating enterprise renewal. Woodard et al.’s (2013) design capital framework enabled us to interpret and conceptualize legacy EIS landscapes as portfolio-level configurations of EIS capital, technical debt, and EIS option value. This reframing foreground that technical debt is not a single deficit located in ‘the legacy EIS’, but a configuration of obligations across code, architecture, data/analytics, and processes that raise the cost and risk of future digital change. Figure 1 visualizes the theoretical core of our argument. Table 12 summarizes each generative mechanism we identified. We here delineate propositions as testable theoretical claims to specify the boundary condition under which each mechanism is enacted (e.g., a specific debt configuration), the transformation it enables (e.g., the relationship between EIS capital and technical debt), and the outcomes it produces (e.g., shift in EIS option value).OPEN IN VIEWER

OPEN IN VIEWER

Table 12.

Legacy EIS reconfiguration mechanisms and propositions.

Generative mechanism	Mechanism narrative	Proposition
M1: Leveraging operational EIS stability for digital pilots	Explains how incumbent firms leveraged the operational stability embedded in their legacy EIS to initiate new digital pilot projects that would have otherwise been unfeasible	P1 (exploratory activation): In legacy EIS landscapes with low tolerance for change, enacting M1 activates latent EIS capital without increasing architecture debt, thereby increasing EIS option value.
M2: Layering analytics on historical EIS data	Explains how incumbent firms converted long-accumulated data from within their legacy EIS into new digital capabilities	P2 (data conversion): In legacy EIS landscapes with underutilized historical data, enacting M2 converts such records into data-oriented EIS capital and reduces data/analytics debt, thereby increasing EIS option value.
M3: Augmenting legacy EIS with middleware interfaces	Explains how incumbent firms avoided wholesale EIS overhauls by strategically augmenting their legacy EIS through middleware interfaces	P3 (architectural augmentation): In legacy EIS landscapes with fragmented architectures, enacting M3 modularizes EIS capital through stable interfaces, and contains/reduces architecture debt, thereby increasing EIS option value.
M4: Retrofitting legacy EIS for new revenue models	Explains how incumbent firms use financial and control logics embedded in legacy EIS designed for lump-sum product sales, to develop new revenue models in the form of subscriptions, pay-per-use, or outcome-based contracts	P4 (monetization alignment): In legacy EIS landscapes with product-centric revenue models, enacting M4 converts financial routines into monetization-oriented EIS capital and reduces process debt, thereby increasing EIS option value.

Each vertical bar in Figure 1 represents the EIS capital provided by the installed base of an organization’s legacy EIS at successive points in time. The total EIS capital represented by each bar is depicted as a configuration consisting of a portion that is constrained by technical debt (hatched bar) and another portion that is accessible for reconfiguration (grey bar), which represents the organization’s EIS option value. The curved arrows denote that a generative mechanism has been enacted (M1-M4), with its underlying design moves transitioning the total EIS capital provided by the installed base of legacy EIS from one configuration (t_n) to the next (t_n+1). Building on Table 12 and Figure 1, we now put three interrelated theoretical claims forward:

First, the process of legacy EIS reconfiguration is cumulative and path dependent. Specifically, each successive configuration of available EIS capital (t_n) inherits the EIS option value and residual technical debt of its preceding configuration (t_n–1), meaning that enactments of each generative mechanism can only build on – rather than replace – earlier configurational states of available EIS capital.

Second, total EIS capital grows over time. This is because the design moves underlying each generative mechanism introduce new digital capabilities onto the installed base; while either reducing configurations of technical debt or keeping existing level constant; this captures our finding that incumbent firms expanded their EIS capital through reconfiguration rather than by replacing or removing legacy EIS.

Third, and most critically, the generative mechanisms ensure that technical debt does not scale proportionally with EIS capital growth; instead, each enacted generative mechanism selectively contains or reduces specific types of technical debt (e.g., architecture, data, process debt) while making a successively larger proportion of the installed base of legacy EIS accessible.

Taken together, our theoretical claims challenge the prevailing assumption that legacy EIS and technical debt stand in a zero-sum relationship with EIS option value. Instead, the four generative mechanisms we identified explain how organizations can progressively make their installed base of legacy EIS accessible and reusable, ultimately increasing EIS option value. Consequently, rather than treating the management of legacy EIS as a binary choice of either keeping or replacing legacy systems, our work introduces a novel contingency-oriented question: ‘which generative mechanism is appropriate given a particular debt configuration’, and ‘which sequences of design moves activate EIS capital while keeping obligations manageable?’. This fundamental theoretical reframing of technical debt is valuable because it challenges comparatively narrow lenses related to the construct, including the ‘technical debt trap’ (e.g., Rinta-Kahila et al., 2023) narrative through a novel account that shows how debt-laden legacy EIS can be reconfigured into more durable sources of digital option value.

Ultimately, our study addressed critical challenges linked to the future of EIS. First, the installed bases of legacy EIS in many organizations are growing rather than contracting (Lokuge et al., 2025), and so does the technical debt that accumulates with them. The question of how organizations can ‘future proof’ their EIS landscapes without disrupting operational stability will become more consequential, not less, in the years ahead. Our mechanism-based theory provides a vocabulary for analyzing and guiding this evolution through sequences of design moves rather than as a series of discrete modernization projects. Second, emerging enterprise technologies like analytics or AI necessarily layer onto, rather than replace, legacy EIS. To function effectively, these systems depend on historically accumulated data, standardized process logics, or organizational control structures. The question of how legacy EIS can ensure the feasibility, reliability, and scalability of AI-enabled enterprise renewal is, in our view, amongst the most critical emerging questions, with our M2 and M3 providing suggestions for how this development may be facilitated. Third, the economic logic of enterprise operations has been shifting from product-centric transactions to outcome-, usage-, or subscription-based revenue models for some time (Sebastian et al., 2017), a trend that is increasing already (Heinz et al., 2022). One implication of this shift for the future of EIS is that financial legacy EIS must support revenue architectures that blend transactional lumpsum and outcome-based billing. This shift places financial legacy EIS under increasing pressure to evolve, with our M4 demonstrating how it may proceed without replacement. Finally, legacy EIS reconfiguration is, of course, but one of several potential future-proofing strategies available (cf. Table 1), and our findings should not be read as universal prescription. Whenever organizations operate as platform mediators or pursue greenfield digitalization, strategies such as wholesale replacement or platformization may be more appropriate. Conversely, legacy EIS reconfiguration is most consequential in incumbent, asset-intensive contexts where legacy EIS embody non-substitutable organizational assets, where deeply embedded process, data, and control logics constitute genuine sources of value, and where reliability, compliance, or switching-cost considerations render wholesale replacement infeasible (Grover and Lyytinen, 2023). The focus of our present work was precisely to address the challenges associate with ‘future proofing’ EIS landscapes in these contexts. The four generative mechanisms (M1–M4) we put forward offer a vocabulary and operational pathway for reconfiguring legacy EIS into ambidextrous EIS landscapes that sustain operational stability while enabling enterprise renewal in incumbent firms. In this sense, our contribution to this Special Issue’s effort to chart the future of IS in the Journal of Information Technology, is not only by clarifying what one such future may look like, but also by specifying when and where it can apply.

Managerial implications

Digital leaders are often blamed for clinging to legacy systems, tolerating technical debt, or failing to build ‘digital native’ capabilities. Indeed, the managerial discourse views technical debt as a largely self-inflicted obstacle to digital change (Banker et al., 2021; Fürstenau et al., 2019; Sebastian et al., 2017). We counter this framing: incumbent firms can work with, not against, their legacy EIS. Instead of relying on heroic ‘rip-and-replace’ programs, we encourage practitioners to draw upon the design moves we identified within each generative mechanism to, for example, leverage operational stability, activate data-oriented EIS capital, or retrofit financial systems for new revenue models. We now translate our findings into actionable managerial insights:

First, treat legacy EIS as a starting point for digital change rather than a barrier. Legacy EIS embody substantial EIS capital: consistent data structures, reliable processes, established workflows, and other reusable assets are instances of EIS capital that can trigger the development of new digital capabilities. Instead of asking “how do we remove old systems?”, managers should ask, “where is our installed base stable enough to support safe experimentation?” For example, telematics stacks or shop-floor routines can be low-risk sandboxes for piloting IoT features, AI-driven analytics, or predictive maintenance. Similarly, decades of operational data can be cultivated as EIS capital for failure prediction, performance optimization, or advisory services. In any case, we suggest selecting pilot use cases that deliberately reuse existing identifiers or workflows; and to overlay new dashboards or apps on top of legacy EIS.

Second, adopt a revenue-generating lens on what others label ‘technical debt’. Legacy EIS contain domain knowledge and financial logics that can be reconfigured to support new revenue models. For example, existing ERP structures can be adapted to support subscriptions, pay-per-use, or outcome-based contracts, often with minimal changes to legacy EIS. However, this requires viewing technical debt and EIS capital through a revenue-generating lens. Rather than asking “what does our architecture prevent us from doing?”, leaders can ask, “which parts of our legacy EIS can we reuse to make new revenue-generative approaches feasible?” This may include using existing finance modules to handle recurring charges based on operating hours; leveraging established contract templates to manage risk in outcome-based agreements; or redefining incentives (e.g., subscription sales) so that recurring revenue is supported rather than penalized.

Third, bridge rather than replace; build ambidextrous architectures. For many incumbents, operational continuity is mission-critical, whereas wholesale EIS overhauls are infeasible. We instead suggest managers bridge legacy EIS with cloud and API-driven middleware interfaces to create EIS landscapes wherein legacy EIS remain stable systems of record while new digital tools foster rapid change. We demonstrated how each incumbent separated stable domains (e.g., finance) from fast-changing domains (e.g., analytics); exposed capabilities of the former via APIs, before routing new digital initiatives through shared platform components. To replicate these undertakings, managers should use cloud-based technologies to augment legacy systems rather than replacing them; define and enforce interface contracts that shield fragile cores while making their capabilities accessible; and establish dedicated teams to manage these assets. Ultimately, the challenge managers face is not a binary choice between keeping or replacing legacy EIS, but orchestrating design moves that rebalance technical debt and EIS capital so that their installed base becomes an enabler, rather than barrier, of enterprise renewal.

Limitations

We acknowledge possible limitations related to our method, research context, as well as the conceptual framing of our theory building process. First, as value-aware researchers, we acknowledge that any reality examined is imperfectly apprehensible, and that our findings are only probably true (Guba and Lincoln, 1994). Participants had to rely on memory when answering questions and may have attempted to influence us. We minimized potential biases by collecting secondary data, by engaging informally with participants on-site, and by conducting interviews across hierarchical levels. At the time of each interview, none of the EIS reconfiguration projects had been completed for more than 12 months so that participants could recollect events well.

Second, like other empirical IS studies, our data collection took place in a specific socio-cultural context and during a particular point in time, specifically within the German manufacturing sector. While this analytically informative empirical setting was deliberately bounded to ensure comparability of findings, we cannot claim that our findings are context independent. As such, we do not claim to provide statistical, but instead analytic generalization through the empirically grounded, mechanism-based theory of EIS reconfiguration in incumbent firms. Importantly, mechanism-based theorizing does not identify deterministic mechanisms, and our mechanism-based theory of EIS reconfiguration in incumbent firms should not be interpreted as such (Sandberg et al., 2020). Other organizations in contexts resembling ours may thus achieve comparable outcomes through alternative pathways, and the mechanisms we identify are not claimed to be necessary or sufficient for successful reconfiguration in every instance. Specifically, while we presented each generative mechanism separately, organizations may mix or sequence them to suit local circumstances, further underscoring the study’s context-sensitive nature. We suggest that our findings are most transferable to other incumbent, asset-intensive B2B organizations in which legacy EIS remain critical to ongoing operations; where ongoing digital initiatives are layered onto, or tightly integrated with, an installed base of legacy EIS; and where reliability, compliance, or switching-cost considerations constrain wholesale replacements of these legacy EIS. As such, transferability of our findings is likely less pronounced to greenfield or digital-native settings, or in industry contexts where future proofing strategies like wholesale replacement or platformization are better suited. The contextual conditions in our CMO narratives should therefore be read as scoping conditions that help readers assess whether, and to what extent, our insights are applicable in other scenarios.

Finally, the literature included in the conceptual framing of our theory-building process may constitute another limitation. We followed Eisenhardt’s (1989) recommendations and initially compared our emerging empirical findings with relevant literature, such as work on technical debt (e.g., Rinta-Kahila et al., 2023) or the role of EIS in organizational settings (e.g., Henfridsson and Bygstad, 2013). However, work from other disciplines may have contributed findings that could be equally applicable. Therefore, we do not claim that the literature included here has been presented in its entirety. Ultimately, “no methodology is perfect” (Leonard-Barton, 1990: 260), and the limitations we identified stand in contrast to the choices we made.

Future research opportunities

Our study presents an important foundation for future research. The first avenue involves extending the conceptual foundations of legacy EIS reconfiguration. Like all social processes, EIS reconfiguration is affected by its settings (Leidner and Kayworth, 2006), which provides the opportunity to further examine underlying boundary conditions, such as how constructs like stereotypes (Huetten et al., 2019) or trust (Someh et al., 2019) may affect each generative mechanism. In addition, other theoretical lenses, such as organizational imprinting (Dias et al., 2023), might provide insights into how legacy EIS could be viewed as ‘imprints’ to digital innovation. For example, the question arises as to whether incumbent firms are more likely to actively re-imprint themselves through internal agency or be re-imprinted by their environment.

Second, future research could provide additional contextual insights. This includes replication studies in other contexts such as healthcare (Huetten et al., 2019), financial services (Tana et al., 2023), or even developing countries (Ramadani et al., 2023), as these offer exciting possibilities to provide novel complementary perspectives on how legacy EIS are used and reused.

Finally, new methodological avenues, including ethnographic or longitudinal research may be useful. Future studies could explore the long-term effects of legacy EIS reconfiguration on firm performance and organizational culture. These questions could be explored through polar case studies that compare successful and unsuccessful instances of legacy EIS reconfiguration. Additionally, the mechanism-based theory we developed could be further explored or empirically tested through agent-based simulations (Torres Pena and Breidbach, 2021) or action research approaches (Sein et al., 2011), which could also foster academic-practitioner collaborations to maximize the practical contributions of future research (Baskerville et al., 2023; Davison, 2023).