JSM - Project overhaul or Start a new project and migrate?

[Kurtis]

Hello,

My current dilemma: 

• We jumped into JSM and set up a very basic Company Managed project with only a couple issue types to make the transition easy for the users.
• Now we're in a place where we need more user guidance during the portal submissions to help cut down on issue triage and info gathering by the techs. 
• From my perspective, our current project is kind of messy given all the scraping together configs on the fly. 
• The current project is also missing a lot of what is present in the pre-made templates provided by Jira. 

My inquiry:

• Generally speaking, is it worth starting a new project, developing it in the background, and migrating over tickets? 
• Or would it make more sense to clean up the current project and build out our needs in there? 
• I want this to be smooth for us and be the least amout of work required. 
• I want to limit the negative impact of the transition on both techs and users. 
• Does Jira tech support offer any remote assistance with this? 

I'm not a pro in the system, but I know my way around pretty well and I can follow well written instructions. 

[Ste Wright · Accepted solution]

Hi @Kurtis 

Whether it's best to start a new Project or not will depend on how much change management this could incur.

For example...

• The Project name/key will change, will this be an issue for existing Filters? Dashboards? Confluence pages?
• How many Customers/Organizations are setup in the current model which would need to be moved across?
• Are there Automation Rules specific to the current design?
• Would a period of time whilst making the switch be detrimental to customers? EG. if there was a period of time with 2 portals?
• ...etc

---

You could do either, but I do find cleaning a Project is often less impactful from a change perspective - even if starting a new Project is simpler for an Admin.

I would consider...

• Creating a new Project, and hiding it from the Portal, to use for testing
• Once testing is complete, migrate changes into the current Project

...this lets you trial, test and demo new features to customers, without any material impact on their existing experience.

This also allows you time to get buy-in for new designs and build excitement with users - to help mitigate change concerns.

---

In terms of getting assistance with designs, or re-configuration, Atlassian Support might offer general advice, and you're welcome to ask questions here in the Community!

But if you want hands-on assistance, I'd recommend contacting a Solutions Partner for help - you can see a list of partners based on location here: https://partnerdirectory.atlassian.com/

Ste

[Kurtis]

Thank you for such a detailed answer. 

Looks like I will develop in a test project and migrate changes to the original. 

I need to brush up on how to tidy up the existing project.

[Ste Wright]

If you do need any guidance, feel free to ask questions here in the Community :)

Ste

[Kurtis]

Are there any good resources for cleaning up a Cloud instance of JSM? 

[Ste Wright]

There is guidance on best practice - check out help pages such as: https://support.atlassian.com/jira-service-management-cloud/docs/best-practices-for-jira-service-management/

But guidance on how to clean your Cloud instance could be quite bespoke - because the right approach will depend on your specific designs and current issues!

Perhaps check out this article as a general starting point? - https://community.atlassian.com/t5/Jira-Cloud-Admins-articles/Jira-Software-Instance-Cleanup-Guide/ba-p/2136279

Ste

[waqas Wilan2026]

Deciding whether to overhaul an existing project or start a new one and migrate depends on several factors, including the scale of changes needed, the complexity of the current project, and your team's resources and expertise. Here's a breakdown to help you decide:

Project Overhaul:

1. Less Disruption: Overhauling an existing project can be less disruptive since you're working within an established framework. It allows you to maintain continuity for existing users and processes.

2. Cost-effective: It may be more cost-effective to overhaul if the changes needed are relatively minor or if the current project has a solid foundation that can be built upon.

3. Risk Mitigation: Overhauling allows you to mitigate risks associated with starting from scratch, such as uncertainties in requirements, development timelines, and potential technical challenges.

Start a New Project and Migrate:

1. Fresh Start: Starting a new project provides a fresh start and allows you to incorporate the latest technologies, best practices, and lessons learned from previous projects.

2. Scalability: If the changes needed are extensive or if the current project's architecture is not scalable, starting anew may be more efficient in the long run.

3. Improved Efficiency: A new project allows you to streamline processes, refactor code, and eliminate technical debt, potentially leading to improved efficiency and maintainability.

4. Opportunity for Innovation: Starting from scratch opens up opportunities for innovation and creativity, allowing you to explore new ideas and approaches without being constrained by existing code.

Ultimately, the decision depends on your specific situation and goals. If the current project's foundation is solid and the changes needed are manageable, overhauling may be the way to go. However, if the existing project is outdated, lacks scalability, or requires extensive changes, starting fresh and migrating may be a better option. Consider factors such as timeline, budget, resources, and the long-term vision for the project when making your decision.

[Mohamed Adel]

Hi Kurtis, 

You can start a new project to apply all the required customization one by one as John mentioned , better not to apply all changes at once, once you have confidence with the applied process/customization you can migrate the issues during the non-working hours and change the project name/key to be similar to the old one (after deleting the old project)

[John Funk]

Hi Kurtis,

My advice would be to work with what you have and clean it up. Switching project names on people can lead to more chaos. 

Take one thing at a time (probably the biggest pain point) - enhance it nicely and then move on to the next item.