8 Key Challenges in Insurance Software Implementation (and How to Avoid Each in 2026)

Why insurance software implementation challenges matter in 2026

In my experience working with U.S. P&C carriers between $500M and $5B GWP, every CIO I have advised in the last 18 months opens the conversation about a core platform replacement the same way: “Show me where the project goes wrong. I do not need vendor success stories - I need the failure post-mortems.” That is a healthy starting point, because the failure rate on insurance software implementations has not improved as much as the vendor pitch decks suggest.

The numbers behind the conversation: a long-running Aite-Novarica observation is that fewer than one in three insurance core platform implementations are considered fully successful by the carrier itself two years post-go-live. Gartner has separately documented that 70-80% of insurance IT budgets go to maintaining legacy systems, which means the modernization budget is already constrained when the project starts. Carriers do not get many shots at this.

I run the company that has shipped 100+ insurance projects since 2003. What I tell every CIO who calls me before signing a vendor contract: “The eight challenges I am about to walk you through are not theoretical. Every one of them has cost a real carrier real money and real time in the last 24 months. If you can answer how you will handle each of these before you sign, your project has a chance. If you cannot, you are buying the right to discover them at vendor day rates.”

For mid-tier carriers specifically, insurance software implementation challenges matter more than they do for $5B+ enterprise, because the mid-tier has less budget cushion, less IT staff to absorb timeline creep, and less Board patience for a 36-month program that started as 12. The same challenges that an enterprise carrier can throw money at will end a mid-tier carrier’s modernization program.

This article is the implementation reality companion to our Pillar Main on legacy-to-modern modernization for U.S. carriers in 2026. The Pillar Main covers the strategic decision (Build vs Buy vs Partner, vendor landscape, 5-year TCO); this one is the on-the-ground view of where projects break.

What are the biggest challenges in insurance software implementation?

The biggest challenges in insurance software implementation are data quality and migration from legacy systems, undocumented business logic held in senior employees’ heads, 50-state regulatory carve-outs for U.S. P&C carriers, vendor industry expertise gaps, change management across 200-2,000 person carriers, talent retention through an 18-36 month project, and vendor timeline creep from initial claims of 12 months to actual delivery of 24-36 months. These eight challenges show up in 80-90% of insurance core platform implementations regardless of vendor, carrier size, or product line.

The pattern is not random. It reflects the structural reality of insurance: a 15-30 year old legacy core that holds the carrier’s actual book of business, business logic that nobody documented because it lived in the underwriters’ heads, a regulatory surface area that varies by state, and an IT operation that has not done a core replacement in 10-15 years and therefore has no institutional memory of how it goes wrong.

The 8 challenges at a glance

The remaining sections walk through each challenge with the specific failure mode I have seen, the early warning signal, and the mitigation pattern that actually works.

The 12-month vendor claim and the honest 18-36 month timeline

The single most common pre-project failure I see is the carrier accepting the vendor’s 12-month implementation claim without testing it. The vendor’s 12-month claim is, in most mid-tier P&C carrier contexts, a marketing number. The honest range for a mid-tier U.S. P&C core platform replacement is 18-36 months from contract signature to first production go-live, and 24-48 months to retire the legacy system completely.

Where the 12-month claim comes from

The 12-month figure traces back to a few specific vendor scenarios that are not generalizable. It applies when the carrier is a digital-only personal lines insurtech with no legacy data, when the implementation is one product line with simple state coverage, when the vendor is replacing a previous instance of the same vendor’s product, or when the “implementation” is a SaaS configuration rather than a core platform replacement.

In any other context - multi-line carriers, carriers with legacy COBOL or .NET systems, carriers writing in more than 10 states, carriers with reinsurance ceded reporting complexity - the 12-month claim is a planning fiction. The carrier will discover this around month 9, when the vendor proposes a “Phase 2” that was not in the original scope.

What 18-36 months actually breaks into

The fastest end of this range, 18 months, requires near-perfect conditions: a single product line, strong existing IT operating model, clean legacy data, no acquisition complexity, and a vendor with deep insurance domain expertise. The slow end, 36 months, is what I see when any one of those conditions fails. The very slow end, 48 months and beyond, is the published failure case study - Sarah does not want to be that case study.

My take on the timeline conversation

I recommend not even starting the RFP until the carrier’s Board has accepted an 18-36 month planning baseline. If the Board is committed to a 12-month timeline, the project will fail at month 13 when the cutover does not happen and the vendor invokes Phase 2. That conversation will get worse, not better, the longer it is delayed. Honest framing at the outset is cheaper than a CEO conversation in month 15.

The 8 critical challenges I see in 100+ insurance projects

In my experience, the same eight challenges show up in roughly the same order on every mid-tier P&C core replacement. The carrier that has a written plan for each challenge before contract signature ships in 18-24 months. The carrier that discovers them sequentially ships in 30-36 months, or does not ship at all.

Challenge 1: Data quality and legacy migration

I have worked with carriers running 15-30 year old systems: COBOL on mainframes, DB2, AS/400, early-2000s .NET PAS platforms, and a handful of Access databases that one underwriter built in 2008 and never told anyone about. The data has accumulated 20+ years of business rule changes, regulatory carve-outs, manual corrections, and exception handling that lives in code comments rather than data documentation.

The failure mode: the migration project assumes that “data is data” and that ETL tools will handle the move. The data quality issues become visible in user acceptance testing, when the new system rejects 8-15% of records that the legacy system was silently accepting through legacy quirks. The fix takes 3-6 months and lands in the “Phase 2” that was not in the original budget.

The mitigation: budget for a data quality assessment as a pre-contract activity, not as a project deliverable. I cover the deeper mechanics in our data migration challenges article, which goes into Strangler Fig pattern, anti-corruption layers, and how to sequence the migration.

Challenge 2: Undocumented business logic in senior underwriters’ heads

This challenge is universally underestimated. The carrier has 15-25 years of business logic that nobody wrote down because the people who knew it were still working. The logic lives in the heads of three senior underwriters, two compliance analysts, and one IT person who has been there since the mainframe install. None of them have time to be interviewed for the new system. Two of them are within five years of retirement.

The failure mode: the new system goes into UAT and the underwriters reject the workflow because the system does not handle the seventeen edge cases they have been handling by hand. The vendor classifies these as “out of scope” or “configuration changes.” The discovery work that should have happened in months 1-6 happens in months 18-24, at twice the cost.

The mitigation: spend the first 90 days of the project doing structured interviews with the senior subject matter experts. Record the sessions. Build the business logic library before the vendor builds the system. I have not seen a carrier do too much of this. I have seen many carriers do too little.

Challenge 3: 50-state regulatory carve-outs

U.S. P&C insurance is fifty different regulatory regimes wearing one country’s flag. New York DFS has Cybersecurity Regulation 23 NYCRR 500 requirements that are different from California’s Department of Insurance rate filing process, which is different from Florida’s hurricane modeling requirements, which is different from Texas’s prompt payment rules. The NAIC Model Bulletin on AI adds another federal-style layer that states implement at different speeds.

The failure mode: the implementation scope was written assuming “U.S. regulatory compliance” as a single line item. State-by-state work surfaces in month 12-18, when the carrier tries to file the first rates on the new system and the state DOI rejects them. Then the same pattern repeats for the next eleven states.

The mitigation: state regulatory mapping is a 4-8 week pre-implementation work product. The carrier’s compliance director and the vendor’s regulatory team should produce a state-by-state matrix before the build phase starts. If the vendor does not have a regulatory team that can do this, the vendor is generic, not insurance-specialized.

Challenge 4: Vendor industry expertise gap

The vendor selection page of every RFP says the vendor has “deep insurance expertise.” The implementation reveals what that means in practice. A vendor with three insurance projects on its resume is not the same as a vendor with 30. A vendor that has done life insurance is not necessarily prepared for P&C complexity. A vendor that has done personal lines is not prepared for commercial multi-line.

The failure mode: the project starts and the vendor’s analysts are asking the carrier’s underwriters to explain annexation, endorsement chains, and reinsurance ceded reporting. Each explanation is a billable hour, and the project is paying the vendor to learn the carrier’s business at the carrier’s expense.

The mitigation: require named insurance domain references in the RFP. Talk to those references before contract signature. Ask the references specifically how many insurance-specific surprises the vendor hit during implementation. Decerto’s Higson platform has shipped 100+ insurance projects since 2003 - depth is the difference, and I will let the case studies page speak for itself rather than make this section a sales pitch.

Challenge 5: User experience and interface familiarity

The new system has to be usable by the carrier’s existing workforce - underwriters who have used the legacy system for 10-15 years, agents who learned the legacy quoting tool in 2008, claims adjusters who built workflows around the legacy claims system’s quirks. The new system’s “modern UX” is not automatically friendlier than the legacy system that users actually know.

The failure mode: parallel run starts, and underwriters quietly continue using the legacy system for “complicated cases” because the new system requires more clicks for the same task. The volume on the new system stays artificially low, defects do not surface, and the project ships a system that works in the demo but not in production volumes.

The mitigation: usability testing in the discovery phase with the actual operators, not the IT team. Workflow mapping for the top-20 most frequent task patterns. Iteration on the UX before the build phase locks the design. The Warta eAgent system implementation - which modernized distribution for 40,000+ agents - is a case where the UX work was a critical success factor, not a final-quarter polish.

Challenge 6: Change management across the carrier

A core platform replacement touches every department: underwriting, claims, billing, reinsurance, compliance, finance, IT, agent operations. Each department has its own workflow, its own concerns, and its own informal power structure. The change management work is usually budgeted at 5-10% of the project and the project actually needs 15-25%.

The failure mode: the system goes live and the resistance shows up in productivity numbers. Sales drop 8-15% in the first month, claims processing slows 10-20%, and the operations team starts blaming “the new system” for everything from coffee machine outages to weather-related claim spikes.

The mitigation: change management leadership reports to the project sponsor, not the IT lead. Department representatives are embedded in the project from the design phase. Training is hands-on, role-specific, and starts before parallel run. The metrics that get reported to the Board include change management indicators, not just IT delivery indicators.

Challenge 7: Talent retention through the project

An 18-36 month project ages everyone working on it. By month 18, the original tech lead has been recruited by a competitor, the project manager is burned out, and senior business analysts have taken offers from insurtech startups. The vendor’s A-team has been rotated onto a new sales opportunity, and the B-team is now running the implementation.

The failure mode: the project loses its institutional memory just before parallel run, when the cumulative knowledge of “why we built it this way” is needed most. New people make different assumptions, re-open closed decisions, and the project slips.

The mitigation: contractually require named individuals on the vendor side, with penalties for unauthorized rotation. Build a project knowledge base in writing, not in Slack messages. Pay retention bonuses tied to milestones, not calendar dates.

Challenge 8: Vendor stretchy timelines

The 12-month claim becomes 18 months at month 9, 24 months at month 18, 30 months at month 27, and 36 months at month 33. Each extension is presented as a small adjustment for “additional scope discovered” or “complexity not visible at RFP time.” Cumulatively, the carrier has approved a 200% timeline extension and not noticed because each step was incremental.

The failure mode: the Board approved the project on a 12-month payback assumption. At month 24 with no production go-live, the CFO can no longer defend the program, and the CEO who approved it is gone. The new CEO inherits a half-finished project and faces a decision: pour more money in, or kill it and write off the sunk cost.

The mitigation: timeline extensions go to the Board with explicit reset of total budget, not just project schedule. Each extension triggers a written re-justification, not a status report. Independent third-party assessment at any extension over 20% of original timeline. The project sponsor reports timeline pressure as a Board-level item, not an IT operational issue.

Why insurance software projects actually fail

Insurance software implementations fail for predictable reasons. After watching this pattern repeat for 20+ years, I have grouped the failure modes into five categories. None of them are about the technology itself - they are about how the project was structured.

1. Failure to do discovery work before build. The project skips or compresses the 90-day business logic capture phase to “save time.” The cost shows up later at 5-10× the savings.
2. Vendor selection on price rather than fit. The lowest-bid vendor wins the RFP. Two years in, the carrier discovers what the missing 15% of the budget would have bought - insurance domain expertise, reference customers with similar profiles, and a vendor team that does not need to learn insurance at the carrier’s expense.
3. Big bang cutover. The project plans a single weekend cutover from legacy to new system. The complexity is too high for a single window. The fallback is parallel run, but the parallel run was not architected, so it does not work. The cutover slips, then slips again.
4. CEO change mid-project. The CEO who approved the project leaves at month 12-18. The new CEO is not invested in the legacy decision and the program loses executive air cover. The project may survive, but at a slower pace and with reduced scope.
5. Trying to fix the business during the implementation. The carrier sees the core platform replacement as an opportunity to also fix billing processes, restructure underwriting authority levels, and consolidate three different agent compensation models. Each business change adds to project risk. Most projects that fail were doing too much, not too little.

The phased rollout pattern - parallel run and cutover playbook

These eight challenges sit at the operational layer underneath the strategic Build vs Buy vs Partner decision I cover in our Pillar Main on legacy-to-modern modernization. The single most effective mitigation against insurance software implementation failure is the phased rollout pattern. The pattern has three components: aggressive parallel run, line-of-business cutover sequencing, and a cutover weekend playbook with multiple dress rehearsals.

Parallel run discipline

Parallel run means both the legacy system and the new system process the same transactions for an overlap period of 3-6 months. The new system’s outputs are compared to the legacy system’s outputs, and discrepancies are triaged. This is not a “test the new system” exercise - it is a “find the data and logic differences before they hit customers” exercise.

For the parallel run to work, the integration layer must support dual writes (every policy write goes to both systems), the reconciliation tooling must be automated (manual reconciliation does not scale beyond a few hundred policies), and the discrepancy triage must have engineering capacity behind it (not just analyst time).

Line of business sequencing

Multi-line carriers should never cut over all lines simultaneously. The sequencing pattern that works for mid-tier P&C: start with the simplest line (often personal property or auto), parallel run for 4-8 weeks, cut over to new system, stabilize for 4-6 weeks, then start the next line. Repeat for each line. The full multi-line cutover takes 12-18 months, not a single weekend.

This is the pattern we used with Higson at Warta for its multi-line modernization across personal lines, commercial, and specialty products. Each line was a discrete cutover with its own parallel run and stabilization window. The Strangler Fig architectural pattern that Martin Fowler documented in software engineering is what enables this approach - the legacy system gets replaced piece by piece, not in a single program.

Cutover weekend playbook

The cutover weekend itself - when a line of business actually switches from legacy to new - needs a written playbook with hour-by-hour timing, named owners per task, decision rights at each gate, and a documented rollback procedure. The playbook gets rehearsed 5-7 times before the actual cutover, with the rehearsals finding the issues that would otherwise surface in production at 03:00 on Saturday.

In my experience, every dress rehearsal finds something. Rehearsals 1-3 find architectural issues. Rehearsals 4-5 find data issues. Rehearsals 6-7 find operational issues (someone’s on vacation, the runbook references a server name that changed). Skipping rehearsals to save time costs 3-10× the time in production recovery.

5-step risk mitigation framework

The carriers I have advised who finish their implementations on time and on budget follow a consistent pattern of risk mitigation. I have distilled it into five steps. The framework is not original to me - it is the consolidation of what I have seen work across 100+ insurance projects.

Step 1: Pre-contract discovery (4-8 weeks, before RFP)

Before any vendor sees the RFP, the carrier produces three artifacts: a state regulatory matrix (every state where the carrier writes, every requirement that affects the new system), a data quality baseline (volume, completeness, known issues per legacy data source), and a business logic inventory (interviews with senior SMEs documenting the rules that are not written down).

These artifacts are not deliverables that the vendor will produce - they are inputs that should exist before the vendor is selected. Carriers who skip this step pay for the vendor to discover all three at vendor day rates.

Step 2: RFP with implementation-specific questions

The RFP includes questions specifically about implementation risk, not just system features. How many P&C implementations has the vendor done at $500M-$5B GWP scale? What is the average implementation timeline from contract to first production go-live, calculated from past references? What percentage of implementations went into Phase 2 scope additions, and what was the average Phase 2 budget?

These questions surface the difference between vendors who have done this work and vendors who are about to learn it on the carrier’s project. I cover the broader vendor evaluation framework in our Build vs Buy vs Partner decision guide, which goes into the full vendor scoring model.

Step 3: Phased scope with milestone-based contract structure

The contract structures the program as a sequence of milestones with explicit gate criteria, not as a single 18-month project with a single payment schedule. Each milestone has acceptance criteria, payment tied to acceptance, and a documented exit clause if the milestone is missed by more than 25%.

This contract structure changes the vendor’s behavior. The vendor cannot push deliverables into “Phase 2” without explicit re-contracting. The carrier has natural exit points if the project is going badly.

Step 4: Independent third-party assessment quarterly

An independent technology advisor reviews the project quarterly. The advisor is not the vendor and is not internal IT. The advisor’s job is to flag patterns that the project team is too close to see: scope creep, timeline pressure, integration risk, data quality regressions.

The advisor reports to the project sponsor (typically the CIO or CFO), not to the project team. The cost of independent assessment is 1-3% of total project budget, and it pays for itself the first time it surfaces a problem before the project team would have escalated it.

Step 5: Board-level transparency with reset triggers

Project status reporting to the Board is structured around the reset trigger pattern: any timeline extension over 20%, any budget overrun over 15%, or any scope addition over 10% triggers an explicit Board-level re-justification. Not a status update - a re-justification.

This structure prevents the slow-creep failure mode where each small extension feels reasonable in isolation, and the cumulative drift is only visible in retrospect. The CFO who has approved three 10% timeline extensions has approved a 33% extension - the framework makes that visible at the time of decision, not in the post-mortem.

Vendor selection - the questions that catch unprepared vendors

In my experience reviewing vendor RFP responses for mid-tier P&C carriers, every vendor sounds confident in writing. The differences surface in specific questions that require operational knowledge rather than marketing copy. These are the questions I tell carriers to add to their RFP - the answers separate insurance-specialized vendors from generic technology vendors with insurance customers.

1. Show me your last three implementation timelines. Original contract date to first production go-live, by reference customer, with permission to call the references. A vendor that cannot produce this is asking the carrier to be the first reference.
2. What percentage of your implementations went into Phase 2 scope additions? A vendor whose Phase 2 rate is 80%+ has a scope discipline problem. A vendor that says “we never do Phase 2” is either lying or is in the configuration-not-implementation business.
3. Show me your data migration methodology for a multi-line carrier. Specifically the data quality assessment phase, the parallel write architecture, and the reconciliation tooling. A vendor that does not have a documented methodology will invent one on the project.
4. What is your state regulatory mapping deliverable? Specifically for NY, CA, FL, TX. A vendor that does not have a regulatory mapping deliverable will discover state-specific requirements during the build phase, at significant cost.
5. Who are your named project leads, and what is your retention commitment? Vendors rotate A-teams to sales opportunities. The contract should name individuals and define replacement criteria. A vendor unwilling to name individuals is unwilling to commit them.
6. What is your published cutover playbook structure? Hour-by-hour timing template, dress rehearsal protocol, rollback procedures. A vendor without a published cutover methodology will improvise during the actual cutover.
7. Show me your reference architecture for parallel run. Specifically the dual-write integration pattern and the reconciliation infrastructure. A vendor without parallel run architecture will recommend big bang cutover, which is the wrong recommendation for most mid-tier carriers.
8. What is your ACORD compliance scope by line of business? P&C AL3 specifically. Multi-line carriers need ACORD compliance per line, and “ACORD-compliant” without per-line detail is not enough.

A vendor that answers eight of these in writing within five business days is operating with implementation discipline. A vendor that hedges or asks to “schedule a call to discuss” is giving the answer indirectly. The depth of the response predicts the project experience more reliably than any other RFP signal I have seen.

For carriers who want a vendor-neutral assessment of where they are in this evaluation, our services for insurance team runs a 4-hour IT Audit that produces a written report covering vendor evaluation criteria, implementation readiness, and risk mitigation specific to the carrier’s context.

‍

FAQ

What are the biggest challenges in insurance software implementation in 2026?

The biggest challenges are data quality and legacy migration from 15-30 year old systems, undocumented business logic held in senior employees’ heads, 50-state regulatory carve-outs varying by NY, CA, FL, TX and other states, vendor industry expertise gaps, change management across 200-2,000 person carriers, talent retention through an 18-36 month project, and vendor timeline creep from initial 12-month claims to actual 24-36 month delivery.

Why do insurance software projects fail at such a high rate?

Insurance software projects fail for predictable reasons: skipped pre-build discovery work, vendor selection on price rather than insurance domain fit, big bang cutover patterns instead of phased rollout, CEO change mid-project that removes executive air cover, and trying to fix multiple business processes during the same implementation. Each of these failure modes is structural, not technical.

How long does an insurance software implementation actually take for a mid-tier U.S. P&C carrier?

A realistic timeline for a mid-tier U.S. P&C carrier ($500M-$5B GWP) is 18-36 months from contract signature to first production go-live, plus 6-12 months to retire the legacy system completely. The fastest end of the range requires near-perfect conditions including a single product line, strong existing IT, clean legacy data, and a vendor with deep insurance domain expertise. The 12-month vendor claim is typically a marketing number, not a planning baseline.

How do you avoid insurance software implementation problems before the project starts?

The most effective prevention is pre-contract discovery: produce a state regulatory matrix, a data quality baseline, and a business logic inventory before the RFP is issued. Then structure the contract with milestone-based payments, named individual project leads, independent third-party quarterly assessment, and Board-level reset triggers for any 20% timeline extension or 15% budget overrun. These structural decisions prevent most of the failure modes that surface mid-project.

What is the most common reason insurance software implementations go over budget?

The most common reason is vendor timeline creep through incremental “Phase 2” scope additions. The 12-month vendor claim becomes 18 months at month 9, 24 months at month 18, and 36 months at month 33. Each extension is presented as a small adjustment, and the cumulative drift is only visible in retrospect. The mitigation is Board-level reset triggers for any 20% timeline extension, not status updates.

Should mid-tier carriers do a single big-bang cutover or phased rollout?

Mid-tier carriers should always use phased rollout, never big bang cutover. The phased pattern involves line-of-business sequencing where each line goes through its own parallel run and cutover, separated by stabilization windows. Multi-line P&C carriers typically take 12-18 months for full multi-line cutover. The Strangler Fig pattern documented by Martin Fowler is the architectural pattern that enables this approach.

Talk to Decerto about IT Audit and Architecture Review

Insurance software implementation challenges are not theoretical. Every challenge in this article is a specific failure mode I have watched compound on a real carrier’s project, with real cost and real Board consequences. The mid-tier carriers who handle them successfully are the ones who do the pre-contract work, structure the program with reset triggers, and choose vendors with insurance domain depth rather than the lowest RFP price.

In my experience, every carrier that has tried to do this assessment from vendor demos has spent 6-12 months and significant consulting fees before reaching the same answer that a vendor-neutral 4-hour review would have produced.

What we offer: a free 4-hour IT Audit with a senior architect from Decerto. The output is a 25-30 page report covering the carrier’s implementation readiness, the realistic timeline range for their specific context, the eight challenges scored for their profile, a vendor evaluation framework calibrated to their lines of business, and a 5-year TCO range with documented assumptions.

It is not a product demo or a sales pitch. The audit can recommend that the carrier delay implementation by 6-12 months to do pre-contract work first, and we have written that recommendation more than once. The output is an honest assessment the CIO can defend to the Board, regardless of which vendor wins the eventual RFP.

The 20+ year context: Decerto has shipped 100+ insurance projects since 2003, with named carriers including Allianz Poland, Warta (HDI/Talanx Group), InterRisk (Vienna Insurance Group), and BNP Paribas Cardif. The BNP Paribas Cardif centralized claims handling implementation on Higson and the Allianz Poland product management modernization are documented examples of the phased rollout pattern delivering on time. Higson, our flagship product after 20+ years of insurance delivery, is built for mid-tier P&C carriers $500M-$5B GWP. Higson is not the right fit for $5B+ enterprise carriers - Guidewire is the industry standard there. We are honest about that, and we are honest about where Higson does fit.

Sources and citations

1. Aite-Novarica Group. (2024). P&C Insurance Technology IT Spend Report and Implementation Success Benchmarks.
2. Gartner. (2024). Magic Quadrant for Insurance Core Platform - North America.
3. Forrester Research. (2024). The Forrester Wave: Insurance Core PAS Solutions, Q3 2024.
4. McKinsey & Company. (2024). Insurance 2030: The Impact of AI on the Future of Insurance.
5. Deloitte. (2026). 2026 Insurance Industry Outlook: Property & Casualty Insurance.
6. EY. (2024). Global Insurance Outlook: Digital Distribution and Customer Behavior.
7. NAIC. (2023, December). Model Bulletin: Use of Artificial Intelligence Systems by Insurers.
8. NY DFS. (2023). Cybersecurity Regulation 23 NYCRR 500.
9. ACORD. (2025). P&C AL3 and Modern Digital Standards.
10. Fowler, M. (2004). StranglerFigApplication.