|
|
|
|
|
by boboche
1532 days ago
|
|
It went from an highly efficient and customisable ticket/work tracker to a clusterfsck of a feature creep mess that requires 10 clicks to add an item to a custom field, that’s when you remember where to look because if you are not an atlassian PhD, it will take more time to search how to do something than simply implementing it. I am still using it because my team is used to it and I don’t have the time to migrate the 3gb+ Database somewhere else for now.
Actually this is a good point, anyone migrated somewhere else using the backup? What was your experience? |
|
Whenever possible, I've always used SQL backups (MariaDB or PostgreSQL) to clone or restore JIRA instances. The database information will accept changes in the base URL without issues. It makes setting up testing and mimic environments pretty easy.
When I recently had to move a project to a new instance that I didn't have jira-administrator access to, I had to provide the server admins a set of CSV exports of our JIRA project so that it could be imported over properly. All of the tasks subtasks, and linking had to be provided in separate CSV files because JIRA would fail to export more than 20000 entries in a single file.
It took weeks worth dry runs and checkouts to make sure it would be successful. This was because we had to give this other team a long list of custom fields, workflows, and schemes that represented our software development and program management methodologies.
On the transition date, I was out of the office on a prearranged cancer treatment. I still got texts from people freaking out while I was sitting in the cancer ward getting my infusion. I told them that I couldn't even look it anything until I got back in the office after my treatment and recovery period. Thankfully, they managed to limp along get 80% of the issues resolved within 2-3 days.