A migration can address an infrastructure limitation and still create a delivery challenge:
who will do the work while your team continues supporting customers and shipping planned features?
The developers who understand your application may already be responsible for production support, integrations, and important business commitments. Moving them onto modernization creates tradeoffs. Leaving the project untouched keeps the existing limitations in place.
For business and technology leaders, the next step is to define what needs to change, how to evaluate the result, and which responsibilities the team can realistically absorb.
The SignUpGenius migration illustrates how those decisions can connect business priorities with specialized technical expertise. Its experience also provides a starting point for evaluating your own project.
Claim free 30-min consultation
Planning a migration or modernization initiative?
Schedule a free 30-minute consultation to discuss your application, delivery priorities, and the expertise your team may need.
1. Define the operational improvement before choosing the technology
Migration and modernization often overlap, but they describe different kinds of change.
A migration moves an application or workload to another environment, platform, or runtime. Modernization improves how the application is built, operated, maintained, or extended. Moving to a new environment may support modernization, but the move alone does not establish that the business problem has been solved.
Start with the limitation you want to address:
- Does the application take too long to scale when demand increases?
- Is deployment difficult to repeat or recover from?
- Are environment dependencies restricting your options?
- Is maintenance consuming time intended for new development?
In the SignUpGenius case study, the customer described scaling delays, licensing costs, and Windows-related dependencies among the reasons for exploring a different approach. Ortus supported the transition from Adobe ColdFusion and Windows to Lucee and Linux, including containerization.
The project connected technical changes to operational needs.
Apply this to your project: complete the statement, “We are making this change so that ______ improves, and we will evaluate it by ______.”
That gives leadership a reason to invest and the technical team a basis for evaluating options.
2. Separate application knowledge from migration experience
Your internal developers may know the application exceptionally well without having performed the particular migration you are planning.
Application knowledge includes business rules, unusual workflows, integration behavior, and the reasons behind earlier decisions. Migration expertise might include compatibility analysis, environment configuration, containerization, or rollout planning.
A project may need both.
In the SignUpGenius interview, Jojo Serquina, CTO at Lumaverse, described a small engineering team that wanted to maintain its roadmap focus rather than absorb the application conversion.
“We want to continue with our roadmap.”
Ortus brought specialized migration and infrastructure experience to the work. The case also describes how an Ortus engineer recommended containerization as part of the approach.
Apply this to your project: identify what your team knows, what it needs to learn, and where relevant outside experience could reduce uncertainty.
This does not automatically mean adding a permanent role. It creates a clearer basis for deciding whether to develop the skill internally, hire for an ongoing need, or bring in specialized support.
3. Validate the result against the original problem
A successful move to a new environment is one milestone. Demonstrating that the change addresses the original limitation is another.
The SignUpGenius interview describes load and scaling testing during the project. The customer reported that scaling time decreased from approximately 20 minutes to probably less than a minute following containerization.
That is a reported result from this particular migration, not an expected outcome for every application. Its value as a lesson is the connection between the initial concern—scaling—and the behavior evaluated after the change.
For your own project, agree on evidence before implementation begins. Depending on the objective, that could include:
- Results from agreed load scenarios.
- Verification of critical application workflows.
- A demonstrated deployment and rollback procedure.
- Confirmation that essential integrations behave as expected.
- Documentation of unresolved issues and their owners.
Apply this to your project: choose measures that reflect the business reason for the change. Establish a baseline where possible, and distinguish measured improvements from assumptions.
See the project behind these lessons.
Read the full SignUpGenius migration case study
Source: SignUpGenius migration case study, interview with Jojo Serquina, pages 2–4. The case documents migration work and is not identified as a Staff Augmentation engagement. The planning recommendations in this article are broader takeaways, not a reconstruction of every step in that project.
4. Plan the internal effort that outside support will still require
Specialized support needs context and decisions from your organization.
Someone must explain expected application behavior, clarify business rules, review proposed changes, and accept completed work. If these responsibilities remain undefined, questions can repeatedly interrupt the same senior developers whose time you wanted to protect.
Before the project begins, agree on:
The internal application owner. Who can explain the system and coordinate answers?
Decision responsibilities. Which choices can the specialist make, and which require internal approval?
Review time. When will the team evaluate work and resolve questions?
Protected commitments. Which roadmap priorities must the internal team continue delivering?
Apply this to your project: include internal collaboration time in the plan. Outside support adds expertise and capacity, but it still needs a workable relationship with the people accountable for the application.
5. Treat maintainability and knowledge transfer as deliverables
The project should leave your team able to operate what has changed.
Define what the internal team will need to understand about configuration, dependencies, deployment, troubleshooting, and future updates. Include walkthroughs and documentation in the work rather than leaving them until the final handoff.
Ask:
When the external support ends, who will own this—and what will they need to maintain it?
That question helps prevent a completed technical change from becoming a new concentration of knowledge outside your organization.
Apply this to your project: include an internal owner, useful documentation, and demonstrated understanding in the acceptance criteria for the relevant work.
What these insights reveal about the support your team needs
Once the work is defined, the expertise gap becomes more specific.
You may need someone to investigate compatibility, implement a migration stage, improve the deployment process, or provide technical direction. You may also need experienced development capacity to keep existing commitments moving while internal specialists focus on the change.
These are different responsibilities. They should shape the support model.
| Your project needs | Support to evaluate |
|---|---|
| Additional implementation capacity within your existing delivery process. | An embedded specialist with defined responsibilities. |
| Experienced guidance for architecture or migration decisions. | Technical leadership with agreed decision and review responsibilities. |
| A bounded piece of work with clear deliverables and acceptance criteria. | A focused workstream with explicit delivery ownership. |
| Expertise that will be needed continuously across future projects. | Internal skill development or a permanent hire, potentially supported during the transition. |
Staff Augmentation can fit when you need specialized expertise or additional capacity working within your team’s priorities and processes. A separately owned project or workstream may fit a different need.
The decision should follow the work, its duration, and the ownership your organization requires.
Explore Ortus Staff Augmentation and Engagement Options
Use the Capacity Gap Guide to prepare the conversation
Before deciding which role to add, bring the business and technical owners together around one initiative.
Identify the work that is waiting, the consequence of delay, the expertise required, and the responsibilities your team will retain.
Turn your modernization priorities into a clearer capacity brief.
Use our free Capacity Gap Guide to organize delayed work, missing expertise, and ownership needs before your next planning conversation.
Get the Free Capacity Gap Guide
Discuss the project and the expertise it requires
You do not need a complete migration plan to begin evaluating support. Bring the application context, the limitation you want to address, and the roadmap commitments you need to protect.
Find the right support for your next migration or modernization initiative.
Schedule a free 30-minute consultation with Ortus Solutions. We’ll discuss your project, assess the capacity and expertise needs, and help identify the type of specialist or engagement that could fit.
Claim free 30-min consultation
Select Staff Augmentation in the contact form and describe the initiative you want to discuss.
Join the Ortus Community
Be part of the movement shaping the future of web development. Stay connected and receive the latest updates on, product launches, tool updates, promo services and much more.
Subscribe to our newsletter for exclusive content.
Follow Us on Social media and don’t miss any news and updates:
Add Your Comment